The First Build · Session 02 · Dates TBD
Interfaces, APIs, databases, security, and deployment
Ship AIPhoenix, ArizonaPress → to begin
The interface is the visible edge of a much larger system.
Tonight one record crosses every seam. You will see each crossing, break one, and know where to look.
Session one made the build recoverable. Tonight connects the system; session three will teach the agent to verify it end to end.
Act one
APIs stop being abstract the moment you watch a real button create a real request and a real row.
When the screen is wrong, name the last step that was right. That cuts the search area immediately.
| Browser | Server | |
|---|---|---|
| Display | Render and collect input | Return data, not markup assumptions |
| Validation | Fast feedback | Authoritative check |
| Secrets | None | Private keys stay here |
| Database | No privileged connection | Apply access rules |
| Trust | Convenient, never trusted | Verify every claim |
Client validation improves the experience. Server validation protects the system. You need both, for different reasons.
Live build: read the request
POST /api/ideas { "title": "Repair notes" }
request: application/jsonresponse: 201 Createdbody: { id, title, createdAt }network panel: 184 ms
Submit the form with the network panel open. Say the method, URL, payload, status, and response out loud. Then send invalid input and read the failure with the same five questions.
Request in, response out. The status code says what happened; the body carries the useful detail.
Act two
Start with the nouns the product truly needs, not a schema generated for every feature the idea may someday have.
| Field | Why it exists | |
|---|---|---|
| id | Stable identity | Update the right record |
| owner_id | Who may access it | Enforce ownership |
| title | The user's input | Required and length-bounded |
| status | The workflow state | Constrained values |
| created_at | When it entered | Order and audit |
A field without a product decision behind it is future confusion. Add relationships only when the user journey needs them.
The acronym matters less than the path. Each operation is a request with permissions, validation, and a visible result.
Only the happy path
A product path
Error states are not polish. They are part of the contract between the interface and the system.
Exercise: trace all four operations
create → inspect row → update → delete
201: row created for current owner200: status updated403: another owner's record blocked204: deletion confirmed
Run the record through its full lifecycle. After each action, inspect both the interface and the stored row. Add one unauthorized attempt and confirm the server rejects it.
The browser can look correct while the row is wrong. Verify both surfaces before calling the operation done.
Act three
Security lives at the crossings: browser to server, server to database, provider to webhook, repository to production.
Never trust the client. A disabled button is an interface choice, not an access-control rule.
Continuous delivery is useful because every push follows the same path. A production-only failure becomes evidence for the next small change.
Live build: fix the first production-only error
git push → checks → deploy → inspect logs
build passedenvironment variables loaded server-sidefirst deploy: 500 on POST /api/ideasmissing production table fixed — live path passed
Deploy the vertical slice, perform the journey on the live URL, and read the failing request beside the server log. Fix the cause, push again, and repeat the same journey.
A green deployment only proves the bundle built. The session ends when the live product writes and reads the real record.
| Artifact | Proof | |
|---|---|---|
| Data flow | Form → API → database → screen | You traced each crossing |
| Schema | Small model with ownership | CRUD works on the live data |
| Security | Validation, access rules, secrets | Unauthorized request failed |
| Deployment | Repeatable push-to-live path | Production journey passed |
Save the diagram, schema notes, checklist, and deploy evidence in 02-full-stack/. Session three will turn this path into a verification target.
Name the last step that worked.
Next
Next session gives the repository durable context, turns acceptance criteria into checks, and has the agent plan, test, debug, and verify a complete feature.
shipai.club · Free, always