Vibe coding prompts for CRUD app: full stack copy-paste set

What this prompt set builds (plain English)

This prompt set is designed to generate a complete, working CRUD app: the screens people use, the API that handles requests, and the PostgreSQL database that stores the data. It also includes login and role-based access, so different users can see and do different things.

CRUD is just four everyday actions your app needs:

• Create: add a new record (like a customer or task)
• Read: view a list and open a single item
• Update: edit an existing item
• Delete: remove an item (often with a confirm step)

On the front end, you should end up with a predictable set of screens: a list page, a detail page, a create form, an edit form, plus a login page and basic navigation. On the back end, you’ll have endpoints that match those screens (list, get by id, create, update, delete), backed by a Postgres table and simple validations.

Prompt quality matters more than model choice. The model can only follow what you specify. If your prompt is vague, you’ll get mismatched field names, missing routes, incomplete auth, or a UI that doesn’t line up with the API. A tight prompt acts like a contract: UI, API, and database all agree on the same names and rules.

Before you start, decide a few details so the build stays consistent:

• Your main entity and 6 to 12 fields (names, types, required vs optional)
• Roles (for example: admin, manager, viewer) and what each role can do
• Basic rules (who can edit, soft delete vs hard delete, required fields)
• The “happy path” screens you need on day one
• Any constraints (unique fields, date ranges, status values)

If you’re using Koder.ai, this can be one conversation that produces a React UI, a Go API, and a PostgreSQL schema that fit together without manual glue.

Prep worksheet: the few details you need before prompting

A good CRUD build starts with a small set of decisions. Write them down first and your prompts stay clear, your screens look right, and your API matches the database.

Start with one core entity. This is the “thing” your app manages every day (Item, Customer, Appointment). Add a second entity only if it’s truly required on day one (for example, Item needs Category). If you start with three or four, you’ll spend most of your time untangling relationships instead of getting a working app.

Write your entity fields with a type and an example. The example matters because it guides labels, formatting, and validation.

• Field: type - example (notes)
• name: text - "Paper towels" (required, 2-80 chars)
• quantity: number - 24 (min 0)
• reorder_date: date - 2026-02-01 (optional)
• status: enum - "in_stock" | "low" | "out" (default in_stock)

Next, list roles and permissions in plain language. Keep it specific. For many apps, 2 to 3 roles is enough:

• Admin: manage users, full CRUD on all records
• Manager: CRUD on records, cannot manage users
• Viewer: read-only

Finally, create 5 to 10 sample records. These drive realistic UI labels, dropdown options, and sensible defaults. Example (inventory): “Hand soap, qty 6, reorder_date 2026-01-20, status low”.

If you’re building in Koder.ai, paste this worksheet into your first prompt so the platform can keep the app consistent across screens, auth, and the PostgreSQL-backed API.

Base prompt: set the rules for the whole build

Start with one “rules of the road” prompt. It keeps the build consistent across screens, API, and database, and it reduces back-and-forth when you add features later.

Ask for a short plan before any code. You want the model to name screens and routes, tables, and API endpoints. Also require it to state assumptions up front (like what roles exist) and keep those assumptions unchanged unless you approve a change.

Here is a copy-paste base prompt:

You are building a complete full-stack CRUD app.

Tech targets (do not change):
- Frontend: React web app
- Backend: Go REST API
- Database: PostgreSQL

Before writing any code, produce a short plan (max 25 lines) that includes:
1) Screens + key UI components
2) Routes/navigation
3) Roles and permissions
4) PostgreSQL tables (with columns and relationships)
5) API endpoints (method + path) for auth and CRUD

Assumptions:
- If any detail is missing, make a reasonable default and list it under “Assumptions”.
- Keep assumptions consistent across UI, API, and DB. If you must change an assumption, stop and ask.

Rules:
- Use simple, boring CRUD first. No “nice to have” features unless asked.
- Include input validation, basic error messages, and loading states.
- Use clear names that match across layers (same field names in UI, API, and DB).

Non-goals (do NOT implement):
- Payments, subscriptions, invoices
- Complex workflows/approvals
- Multi-tenant org hierarchy
- Real-time chat/notifications

Now ask me 5 clarifying questions max. If I answer “default”, proceed with your assumptions.

A concrete example: if the plan picks role: admin|member, it shouldn’t later invent manager to solve a UI edge case. This prompt forces it to pause and get your approval instead of drifting.

Copy-paste prompts: screens and navigation

Good screens come from a clear page map first. Use the prompts below before you ask for database or API code. This keeps routes and UI names stable later, which is where many builds go off the rails.

Prompt 1: page list and user flows

You are building a full-stack CRUD app UI. Start by proposing a complete page list and user flows.

App concept (1 sentence): <PASTE YOUR APP CONCEPT>
Entities (list): <ENTITY_1>, <ENTITY_2>
Roles: <ROLE_1>, <ROLE_2> (include an Admin role)

Deliverables:
1) A table of pages with: Route, Page name, Who can access, Primary actions, Empty state behavior.
2) Key user flows (bullets): sign up, sign in, create record, edit, delete, search/filter, admin manages users.
3) Route naming rules: kebab-case paths, consistent singular/plural, no duplicates.
4) Component naming rules: PascalCase, one top-level page component per route.
Ask me 5 questions max only if needed.

After it answers, lock the names. If you change route names later, the API and tests will drift.

Prompt 2: navigation and forms that behave well

Using the approved page list and route names, generate:

A) Navigation
- A simple top nav for desktop and a compact mobile menu.
- Show which items appear for each role.
- Add a clear "You do not have access" page and redirect rules.

B) Page skeletons
For each page, create a minimal UI with:
- A visible page title and short helper text.
- Loading state, empty state, error state.
- A primary button for the main action.

C) Accessible forms
For all create/edit forms:
- Labels tied to inputs, required markers, inline validation errors.
- Disable submit while saving, show a spinner, prevent double submits.
- Toast or inline success message after save.

D) Consistent action names
Use these verbs exactly: list, view, create, update, delete.
Use these UI actions: onCreate, onUpdate, onDelete, onSearch.

If the UI comes back too complex, ask it to keep only one layout, one table style, and one form pattern across all pages.

Copy-paste prompts: authentication and roles

If you want predictable results, be explicit about how users log in, how long sessions last, and what each role can do. These prompts assume a simple email + password login and a session-based approach (easy to test across screens and APIs).

Paste this first to generate login, logout, and session handling:

Implement authentication for this app.

Requirements:
- Add UI screens: Login, Logout action, and a simple “My account” page that shows the logged-in user email and role.
- Use email + password login.
- Session handling: keep the user logged in across refresh; include a clear “Log out” button.
- API endpoints: POST /auth/login, POST /auth/logout, GET /auth/me.
- Show friendly error messages for wrong password, unknown email, and locked/disabled accounts.

Security (keep it simple):
- Password rules: minimum 12 characters; must include at least 1 letter and 1 number.
- Store passwords securely (hash + salt). Never store plain text.
- Basic protections: rate-limit login attempts per email/IP and return generic error text that doesn’t reveal which part was wrong.

Deliverables:
- Working UI flows + backend endpoints.
- Seed one default admin user for local testing and tell me the credentials.
- Add clear comments explaining where to change password rules and session duration.

Now add roles and protection rules. Keep permissions small and easy to test:

Add role-based access control (RBAC) with these roles: admin, manager, viewer.

Rules:
- admin: can create, edit, delete, and manage users/roles.
- manager: can create and edit records, cannot delete, cannot manage users.
- viewer: read-only.

Enforcement:
- Protect both routes (screens) and API endpoints. Do not rely on the UI alone.
- If a user lacks permission, show a “Not allowed” page in the UI and return HTTP 403 from the API.

Deliverables:
- A simple “Users” admin screen to list users and change roles.
- A clear table (in text) mapping each route + API endpoint to required role.
- Add automated checks or middleware so every protected endpoint enforces the rules.

Quick manual checks that catch most mistakes:

• Log in as each role and confirm what you can and can’t see.
• Try a restricted action anyway (like delete) and confirm you get 403.
• Confirm logout clears the session and the app returns to the Login screen.

If you’re building in Koder.ai, keep auth and RBAC changes in one snapshot so you can roll back cleanly if permissions get tangled.

Copy-paste prompts: PostgreSQL schema and data model

A good schema prompt does two jobs: it forces clear table relationships (so screens and API stay consistent), and it prevents “almost right” databases (missing indexes, timestamps, or role mapping).

Before pasting, decide these two toggles (one line each):

• Primary keys: uuid or bigserial
• Soft delete: yes (use deleted_at) or no (hard delete)

Paste this first prompt to lock the data model:

You are building the PostgreSQL data model for a full-stack CRUD app.

Domain: <DESCRIBE YOUR APP IN 1 SENTENCE>
Core entities: <LIST 3-6 ENTITIES>

Rules:
- Use PostgreSQL.
- Choose primary key type: <uuid|bigserial>.
- Timestamps: every table must have created_at and updated_at.
- Soft delete: <yes|no>. If yes, add deleted_at and default queries should ignore deleted rows.
- Define users, roles, and permissions storage:
  - users table (email unique, password_hash, status)
  - roles table (name unique)
  - user_roles join table (user_id, role_id) with unique(user_id, role_id)
- For each core entity: define columns, types, required vs optional, and relationships.
- Call out any many-to-many relationships and introduce join tables.
- Propose indexes for common lookups (foreign keys, email, name/search fields).

Output:
1) A short ERD description in plain English.
2) The final table list with columns and constraints.
3) The index list with rationale.

Then paste this prompt to generate migrations or setup steps that match the project:

Now generate the actual database setup for this project.

Requirements:
- Provide SQL migrations (up and down) for all tables, constraints, and indexes.
- Ensure foreign keys and on-delete behavior are explicit.
- Include extensions you rely on (for example uuid generation), but only if needed.
- Add a seed migration for: one admin user, one admin role, and the user_roles link.

Output:
- migrations/ file names in order
- contents of each up/down migration
- brief notes on how to apply migrations in the project

If anything is ambiguous, add one more line: “Ask me up to 5 questions if any relationship or field is unclear before writing SQL.”

Copy-paste prompts: Go CRUD API (Postgres-backed)

If your backend outputs keep coming back half-finished, this prompt forces the basics: clear routes, validation, pagination, and role checks on every handler.

Copy-paste this as-is, then replace the placeholders (RESOURCE, FIELDS, ROLES) with your app details.

You are building the backend API in Go for a Postgres-backed CRUD resource.

Resource
- RESOURCE name (singular/plural): <Item/items>
- Table: <items>
- Primary key: <id UUID>
- Fields (name, type, required?, rules):
  - <name TEXT required, 2..80 chars>
  - <qty INT required, min 0>
  - <status TEXT optional, one of: active, archived>
- Ownership: <tenant_id UUID required> and <created_by UUID required>

Auth and roles
- Roles: <admin, manager, viewer>
- Authorization rules:
  - Every endpoint must check role and tenant_id.
  - admin: full access
  - manager: create, read, update, list; cannot delete
  - viewer: read and list only

API requirements
1) Implement REST endpoints:
- POST /api/items
- GET /api/items/{id}
- PUT /api/items/{id}
- DELETE /api/items/{id}
- GET /api/items

2) Define request/response JSON shapes for each endpoint, including examples.

3) Validation
- Return 400 with field-level errors (clear messages) when invalid.
- Return 401 if no auth, 403 if role not allowed, 404 if not found in tenant.

4) List endpoint
- Support filtering by: <status>
- Support sorting by: <created_at,name> with order asc/desc
- Support pagination: page, page_size; return total, page, page_size, items.

5) Data access
- Use database/sql (or pgx) with parameterized queries only.
- Include migrations SQL for the table and indexes (tenant_id + created_at).

Deliverables
- Go code: routes, handlers, DTOs, validation helpers, repository layer
- SQL: migration(s)
- Notes: any assumptions

After generation, do one quick pass for consistency: status codes match the error body, list endpoint returns stable ordering, and each handler checks both role and tenant ownership before touching the database.

If you’re using Koder.ai, also call out that the backend must stay in Go and the database must stay in PostgreSQL so exported code matches the expected stack.

Step-by-step: generate, run, and verify

Generate everything (UI, API, database), then switch to strict verify mode. The goal isn’t to admire screens. It’s to prove the full loop works: UI - auth - roles - Postgres - API - UI.

A simple verification run

1. Run the app and load the home screen. Confirm navigation works and you don’t see placeholder data. If the page is blank, note the first visible error message (UI toast, console, or server log).

2. Create one test account per role (Admin, Manager, Viewer). Log in and out with each user. Confirm the app shows the role somewhere visible (profile menu, settings, or a small badge).

3. Pick one CRUD screen and do a full cycle: create a record, refresh the page, then edit and delete it. The key check is persistence: after refresh, the record should reflect what’s in Postgres, not just in memory.

4. Try forbidden actions on purpose. Log in as the lowest role and attempt to access an admin-only screen, call a restricted action (like delete), and edit a record you shouldn’t. You want clear results: either a blocked UI with a message, or a 403-style error with no data change.

5. Hit basic edge cases: empty lists, very long names, missing required fields, and invalid formats (email, dates). Confirm the app shows helpful validation and doesn’t crash.

If you’re using Koder.ai, take a snapshot right after the first successful end-to-end CRUD test. It gives you a safe rollback point before you start adding extras.

Common prompt failures and how to fix them

Most “broken” builds aren’t truly broken. They’re missing one constraint that keeps the UI, API, and database moving together.

1) You asked for too much at once

When you request screens, auth, roles, schema, and every edge case in one go, the app often becomes inconsistent (routes don’t match, models drift, half-finished pages).

Fix: split by layer and force the tool to restate what it will generate before coding. In Koder.ai, this also helps keep multiple agents aligned.

2) Roles are vague, so checks go missing

If you only say “admin and user”, you may get a role label in the UI but no real server-side authorization.

Fix: define permissions as actions (create, read, update, delete) per resource, and require server-side enforcement on every endpoint.

3) Missing field types causes UI and DB drift

If you describe fields in plain English (“price”, “date”, “status”), forms may render as text inputs while Postgres expects numbers, dates, or enums.

Fix: specify field types, nullability, defaults, and constraints, and require shared validation rules.

4) No loading and error states, so the UI looks broken

Without loading and error states, a failed request looks like a frozen page.

Fix: require loading spinners, empty states, and visible error messages for each screen.

5) Names change mid-build

Renaming “Projects” to “Workspaces” halfway through often breaks routes, handlers, and table names.

Fix: lock a glossary early. When you do change names, request a rename plan (search, replace, migrate) instead of letting the model improvise.

Use this repair prompt when something goes off track:

Audit the current app and list mismatches between: (1) routes, (2) API endpoints, (3) database tables/columns, (4) UI form fields.
Then propose a minimal patch plan.
Rules: do not invent new names, do not add new features, keep existing behavior, and update tests if present.
Output: a checklist of changes, then apply them.

If you keep hitting inconsistencies, you’re probably missing a “single source of truth” statement. Add one sentence: “The Postgres schema is the source of truth; UI and API must match it exactly.”

Quick checklist before you call it done

Before you spend time polishing, do a fast pass to confirm the app behaves like a real product. This is where most full-stack CRUD apps fail: tiny mismatches between screens, rules, and data.

• Screens match the entity spec: every screen (list, details, create, edit) uses the exact entity names and field list you defined.
• Roles are unambiguous: write a simple allow/deny table per role and confirm the UI and API enforce the same rules.
• API responses are consistent: pick one pattern (status codes, error shape, pagination shape) and verify every endpoint follows it.
• Database constraints match form validation: if the DB requires unique email or non-null name, validate before submit and show a clear message when the API rejects it.
• Create/edit/delete survives a refresh: create a record, refresh, confirm it’s still there; edit, refresh, confirm; delete, refresh, confirm.

A concrete test: log in as the lowest-permission role and try an action you expect to be blocked (like deleting). If it succeeds, fix the policy in one place (the API) first, then adjust the UI to match.

Realistic example: a simple inventory tracker

Picture a small IT team that lends laptops, monitors, and adapters to staff. They need one place to see what’s available, who has what, and when it’s due back. This is a good test case because it forces roles, a few screens, and a real database.

Filled-in prep worksheet

Use this as the exact input for your prep step (copy as-is, then tweak names):

App name: IT Equipment Loans
Goal: Track inventory and loans. Staff can request items. Admin approves and records check-out and return.
Roles:
- admin: manage inventory, approve/deny requests, edit any loan, see all
- staff: browse inventory, create a request, see own requests/loans
- viewer: read-only access to inventory and aggregate loan status
Core screens:
- Login
- Inventory list + item detail
- Request item (staff)
- Admin requests queue
- Loans list (filter: active/overdue)
Data rules:
- An item can have 0 or 1 active loan at a time
- Due date required for approved loans
- Overdue if due_date < today and not returned
Sample data:
- Items: MacBook Pro 14 (MBP-014), Dell 27 Monitor (MON-227), USB-C Dock (DOC-031)
- Users: alice(admin), ben(staff), carla(viewer)

Paste order

Paste your prompts in this order so the app stays consistent:

1. Base prompt (global rules, tech stack, naming, error handling)
2. Screens and navigation (Inventory, Requests, Loans, Admin queue)
3. Authentication and roles (admin, staff, viewer permissions)
4. PostgreSQL schema and seed data (items, loans, requests, users)
5. Go CRUD API (endpoints and validation that match the rules)

A good outcome looks like this: staff can request “MBP-014”, the admin can approve it with a due date, and the inventory list shows it as unavailable with the borrower name.

If the build is close but not right, adjust one thing at a time: tighten role permissions (viewer should never see edit buttons), restate the “only one active loan per item” rule, or ask it to rename fields so UI labels and database columns match exactly.

Next steps: extend safely and reuse the prompt set

Once the basics work, treat the next changes like small releases. Pick one feature, define what “done” means, then prompt for it.

A sensible order for many apps:

• Audit log: record who changed what and when (create, update, delete), and show it on an admin-only screen.
• File uploads: attach a document or image to a record, store metadata in Postgres, and keep access behind auth.
• Simple notifications: show in-app alerts (for example, “low stock” or “new comment”), with a “mark as read” action.

When a change breaks the build, don’t try to fix everything at once. Roll back, then re-apply the change in a smaller, more specific prompt. If you use Koder.ai, snapshots and rollback are a practical safety net, especially before changes that touch the DB schema, auth rules, or shared UI components.

Planning Mode also helps when a feature spans multiple layers. Ask it to restate the plan first (screens, API endpoints, database changes, roles), then approve that plan before generating code. This prevents the common mismatch where the UI expects fields that the API doesn’t return, or the API writes to columns that don’t exist.

If you want to continue outside the platform, export the source code and make changes in your usual workflow. Keep the prompt set alongside the repo as “build instructions” so you can recreate the app later or onboard someone new.

If you’re building on Koder.ai (koder.ai), this prompt set lines up well with the platform’s React + Go + PostgreSQL defaults, and it’s easy to iterate safely using snapshots while you refine requirements.

Finally, save a reusable template prompt for your next project. Keep the stable parts (stack, CRUD rules, auth and roles conventions, Postgres patterns) and swap only the domain nouns. Over time, your prompts become a repeatable recipe instead of a one-off experiment.