Recap and Practice

Key takeaways

• The spec came first and it was short — a paragraph that named the constraints that mattered, including workflow constraints that never show up in the running app.
• Secrets never touched the repo; every project read keys from environment variables or encrypted config set in a dashboard.
• The stack was chosen so there was less to get wrong — managed auth, managed database, static hosting, serverless functions.
• Obstacles got solved by feeding the AI exact evidence — the literal error, the actual code, the deploy config — and scoping fixes narrowly.
• Launch meant a real test against reality, not "it compiled": a live purchase, a second account, a deep link on the deployed site.

Try it

Pick one of your own ideas and write its one-paragraph spec the way these four did: name the core action, the data each user can see, and at least one workflow constraint (how content gets published, who can do what). Then list the managed building blocks you'd lean on so there's less custom code to break. Keep it to a single paragraph plus a short bullet list — if it grows past that, you're over-specifying.

Prompt of the chapter

I want to build: [one-paragraph description of the app].
Before any code, help me tighten this into a buildable spec.
1. Restate the single core action a user performs.
2. List the data each user can see — and what they must NOT see.
3. Name the workflow constraints that won't show up in the UI
   (e.g. "pushing a file should publish it", "only their own data").
4. Recommend a stack that MINIMIZES custom code: managed auth,
   managed database, static or serverless hosting where possible.
5. Flag the one part most likely to go wrong, and how we'll test it
   against reality (a real purchase, a second account, a deep link).
Keep the spec to a paragraph plus bullets. Push back if it's too big.