What is CRUD? (create, read, update, delete)

What it actually is

CRUD stands for create, read, update, delete. Those are the four operations an app can perform on stored data: save a new record, look records up, change an existing one, remove one. Tutorials and agents drop the acronym as if everyone were born knowing it, yet nearly every feature in every app you use breaks down into some mix of those four verbs.

Think of the contacts app on your phone. You add a contact (create), scroll the list and open one (read), fix a typo in a phone number (update), and remove someone you no longer talk to (delete). That is a complete CRUD app, and it ships on every phone because managing records is what most software does. Here is how the four verbs line up across the layers of a typical project:

What you do	CRUD verb	HTTP method	SQL statement
Save a new note	Create	POST	INSERT
Open your notes	Read	GET	SELECT
Edit a note	Update	PUT or PATCH	UPDATE
Remove a note	Delete	DELETE	DELETE

One nuance in the update row: PUT replaces the whole record, while PATCH changes only the fields you send. Your agent will pick one and usually stick with it. As for the phrase “just a CRUD app,” it means the data handling follows this standard pattern, and it says nothing about whether the app is worth building. A todo list is a CRUD app. So is the CRM a sales team pays for every month.

Why your AI just did this

Agents scaffold CRUD first because it is the skeleton every other feature hangs on. Ask for “a recipe app” and your agent will typically produce three things before anything fancy: a recipes table with its schema, one API endpoint per verb, and forms wired to them. When it reports “set up CRUD operations for recipes,” that is the whole message: the plumbing for saving, listing, editing, and deleting recipes now exists, and nothing else does yet.

The convention runs deep enough that agents reach for it on autopilot. Many web frameworks generate the full set of CRUD routes from a single line of configuration, and REST APIs are organized around the four verbs. So when your agent plans a feature, its first quiet question is which of the four the feature needs. A public blog needs read for everyone but create, update, and delete only for you. A comment section needs all four for every user, which is why comments are more work than they look.

When you’ll run into it

Courses and tutorials use “build a simple CRUD app” as the standard first project, usually a todo list, because it exercises all four verbs in an afternoon. Your agent’s progress messages lean on the same shorthand: “scaffolded CRUD routes for tasks,” “wired the delete button to the API.”

In your own project, CRUD shows up as structure. Open the api/ or routes/ folder and you will find the verbs as routes: POST /api/tasks to create, GET /api/tasks to list, PATCH /api/tasks/:id to update, DELETE /api/tasks/:id to remove. Open your browser’s dev tools, click a request in the Network tab, and its headers show which method it used. And inside your database dashboard, permissions and row-level security rules are defined per operation, which is how an app can let users read records they are not allowed to delete.

What to check

• Ask your agent which of the four verbs a new feature needs before it builds; many features are read-only, and skipping the verbs you don’t need cuts both work and attack surface
• Test all four verbs after a feature ships, updates and deletes break most often because demos only exercise create and read
• Confirm delete does what you intend: many apps soft-delete, meaning they mark the record as deleted and keep the row, which enables undo but means the data still exists
• Match permissions to verbs one by one: who can read a record is a separate decision from who can update or delete it
• Watch for updates without a filter: an UPDATE that is missing its WHERE clause changes every row in the table, a classic bug your agent can write too

Say it like a dev

Instead of: “users should be able to add recipes and change them later” Say: “Add CRUD for recipes: POST to create, GET to list and fetch one, PATCH to update, DELETE to remove”

Instead of: “the edit page doesn’t do anything when I hit save” Say: “The update path is failing. Check the PATCH request in the Network tab and the UPDATE query behind it”

Instead of: “delete is broken, things come back after I remove them” Say: “Deletes aren’t persisting. Check whether the endpoint runs a real DELETE against the database or only removes the item from the UI”