Guides / Concepts explained

What Is CRUD? Create, Read, Update, Delete Explained

CRUD means create, read, update and delete: the four things most apps do with data. How it maps to screens, databases and APIs, and how to ask AI for it.

Mythex Team · 2026-09-29 · 5 min read

CRUD stands for create, read, update and delete — the four basic things an app does with stored data. Adding a new customer is create, viewing the customer list is read, changing their phone number is update, and removing them is delete. Most business apps — CRMs, booking systems, inventory trackers, admin panels — are largely CRUD with rules and a good layout on top.

Why it matters when you build with AI

CRUD is the vocabulary that turns a vague app idea into a precise request. "An app for managing our suppliers" leaves the AI guessing. "Create, list, edit and delete suppliers, with these fields" tells it exactly which screens, database operations and server routes to build.

It also gives you a checklist for testing. For every kind of record in your app, you can ask four questions: can I add one, see them, change one and remove one — and can only the right people do each? A surprising number of AI-built apps can create records but not edit them, or let anyone delete anything.

An everyday analogy: a recipe card box

Picture a box of recipe cards on a kitchen shelf.

• Create: write a new card and file it.
• Read: flip through the box, or pull out the one for lasagne.
• Update: cross out "200g cheese" and write "250g".
• Delete: take a card out and throw it away.

Now add rules: only the head cook can throw cards away, every card must have a title, and nobody can file two cards with the same name. That's a CRUD app with validation and permissions — which is what most real apps are.

How CRUD shows up in each layer

Each operation appears in the screen, the server and the database. Seeing them side by side explains a lot about how apps are built.

The screen is the frontend, the API request is how the frontend talks to the backend, and the SQL is how the backend talks to the database. If those words are new, see what an API is and what a database is.

A worked example: an equipment loan tracker

A school's media department lends cameras and microphones to students and keeps losing track of them. They want a simple app.

The records. Two kinds of things: equipment (name, type, serial number, condition) and loans (which equipment, which student, date out, date due, date returned).

CRUD for equipment:

• Create: staff add a new camera with its serial number. Rule: serial numbers must be unique.
• Read: a list of all equipment, filterable by type and by "available now"; a detail page showing the loan history of one item.
• Update: change the condition to "needs repair".
• Delete: usually not a real delete. If a camera with 30 past loans is deleted, those loan records lose their link. Instead, mark it "retired" so it disappears from the available list but its history stays. This is called a soft delete.

CRUD for loans:

• Create: check an item out to a student. Rule: you can't check out an item that's already on loan.
• Read: "overdue loans" — a list where the due date has passed and there's no return date.
• Update: record the return date when the item comes back.
• Delete: staff only, for loans entered by mistake.

Permissions. Students can read what's available; only staff can create, update or delete. These checks run on the server, not just by hiding buttons.

That is the whole app. The interesting parts — no double-lending, an overdue list, a history per item — are rules and queries on top of plain CRUD.

Key terms

• Record (row): one item, like one supplier or one loan.
• Entity / resource: a kind of record, like "suppliers". Each usually gets its own table and its own set of CRUD screens.
• Validation: checks on input — required fields, valid email, positive quantity. Do it in the form for convenience and on the server for safety.
• Soft delete: marking a record as deleted or archived instead of removing it, so history and links survive.
• Pagination: showing a long list a page at a time, so the app stays fast.
• Audit log: a record of who created, changed or deleted what, and when.
• Admin panel: a set of CRUD screens for staff to manage an app's data.

Common mistakes and misconceptions

• Forgetting one of the four. Apps often ship with create and read but no edit, so every typo means delete and re-enter. Check all four for every entity.
• Deletes that break things. Deleting a customer who has invoices can leave orphaned invoices or erase history. Decide per entity: block the delete, soft delete, or delete related records too.
• Permissions only in the interface. Hiding the Delete button doesn't stop someone sending the DELETE request. The server must check who is asking.
• Updating by ID without checking ownership. If user A can edit /api/notes/42 by changing a number in the URL, they may edit user B's note. Every update and delete must confirm the record belongs to the requester.
• No confirmation on delete. A single mis-tap shouldn't destroy data. Ask for a confirmation step, or an undo.
• "CRUD means basic, so it's not worth building." Many valuable products are CRUD apps that fit a workflow better than a generic tool does.

What to ask your AI builder for

Use this pattern for each entity, one at a time:

Create a suppliers feature with list, create, edit and delete. Fields: name (required), contact email (valid email), phone, category (one of: food, packaging, cleaning), notes. List view with search by name and filter by category, 20 per page. Confirm before deleting; if a supplier has orders, archive instead of deleting. Only logged-in staff can create, edit or archive — enforce this on the server.

Then test all four operations, as a permitted user and as someone who shouldn't have access. Once one entity works, add the next. How to build an internal tool shows how CRUD screens become a full admin app, and what Postgres is explains the database most of these apps sit on.

CRUD apps on Mythex

CRUD apps are one of the things AI app builders do best, and Mythex is no exception. Ask in chat for the entity and its fields, and Mythex attaches a Postgres database to the project, creates the table, and builds the list, form and detail screens in a live preview; you can then run /test to check the flow. The docs have a CRUD app recipe with a starter prompt, and the internal tool builder and dashboard templates are good places to start.