patrickz
Before you start
A coding agent and comfort with a local client/server project. Use fictional data and two test accounts.
Why this lesson exists
The archived LifeTracker project explored separate frontend, API and infrastructure layers. Treat this lab as architecture practice and check current identity-provider guidance instead of copying its older service choices.
Do the exercise
Set your boundary
Build only create-habit and list-my-habits: a local API, two fictional test accounts and a server-side ownership check on every request. Leave deployment and cloud infrastructure until this slice passes its tests.
Pick one vertical slice
Build one vertical slice only: create and list habits.
Define the API contract
Define the API contract before wiring the interface.
Add two test accounts
Add authentication for two fictional test accounts and verify tokens on the server.
Store a user ID on every record
Store user IDs with every record and check ownership on every request.
Test cross-user access
Add tests for cross-user access: user B cannot list, fetch or change user A’s habits.
Next sessions, not today
- Deployment Deploy only after this slice passes its tests, using current identity-provider guidance.
- Infrastructure automation Add infrastructure automation after the local system works.
A prompt to adapt
Replace the bracketed parts with your own details.
Help me build one secure full-stack interaction with [React and Express, or your stack] and TypeScript in a new practice folder. First version only: create-habit and list-my-habits, a local API, two fictional test accounts and a server-side ownership check on every request. No deployment or infrastructure automation yet. List the setup commands before changing any files. Then work in five checkpoints and, after each, tell me how to check it: 1. One vertical slice: create and list habits. 2. Request and response schemas, defined before wiring the interface. 3. Sign-in for the two test accounts, with tokens verified on the server. 4. A user ID stored with every record and checked on every request. 5. Tests proving user B cannot list, fetch or change user A’s habits by direct API calls, and that unauthenticated calls fail. Follow current guidance for [your identity provider].
Once it runs, paste your code and ask:
Review this vertical slice for ownership leaks. Check that every route takes the user ID from the verified token, not the request body, that list, fetch and change all filter by owner, and that tests cover user B and unauthenticated calls. Flag complexity that is unnecessary for an early prototype.
Run this experiment
Create one record as user A. Confirm user B cannot list, fetch or modify it through direct API calls as well as the interface. Test an unauthenticated request.
Check your result
Use evidence from your output. A confident explanation from the AI is not enough.
If it isn’t working
Hiding a button is not authorization. Enforce the boundary on the server, and choose current supported identity services before production.
Optional. Progress stays in this browser.
Where this came from
Public project repository ↗. The practice lesson is an adaptation, not a verbatim transcript. About the sources.
Prepared September 2026. Tools and interfaces change; use current official setup instructions. Session lengths are estimates.