Once you can list records, add one, edit one and delete one, you can build most internal software. Get this pattern right once and it repeats forever.

1. Data first

dashboard-schema.txt
I'm building an admin screen for: <the thing — orders, clients, jobs>

Design the table: columns, types, required, unique, indexes.
Include created_at and updated_at.

Then tell me:
- Which columns belong in the list view versus the detail view?
- What will I want to filter and sort by? Index those.
- Which decision here is expensive to change later?

2. Build the list view

The list is the screen people live in. It needs pagination from the start, sorting on the columns people care about, a search box, and an empty state with an obvious "add the first one" button.

Resist showing every column. Five that matter beats fifteen that need horizontal scrolling.

3. Add, edit, delete

crud-endpoints.txt
Build create, update and delete for <the record>, matching this
existing list endpoint: <paste>

Rules:
- Validate on the server, not just the form. Same rules both places.
- Every route checks the current user is allowed THIS record, not
  just that they're logged in.
- Delete asks for confirmation, and says what's being deleted by name.
- After saving, return to the list with a confirmation message.
- Show validation errors next to the field, keeping what they typed.

That last point is where generated forms usually fall down: a validation error that clears the form is worse than no validation.

4. The details that make it pleasant

Soft delete rather than real delete — a deleted_at column — so a mis-click isn't permanent. Keyboard submit on forms. Loading state on the save button, disabled while in flight so double-clicks don't create two records.

The "are you sure?" dialog should name the record. "Delete this item?" gets clicked reflexively. "Delete invoice #1042 for Acme Ltd?" gets read.