What the four have in common
- The spec came first, and it was short. A paragraph, not a document. But it named the constraints that mattered — languages, "only sees their own data," "still send what you have," "pushing a file should publish it" — including the workflow constraints that never show up in the running app.
- Secrets never touched the repo. Every project read keys from environment variables or encrypted secrets, set in a dashboard, not in code. We said "never hardcode it" out loud, because the default is the opposite.
- The stack was chosen so there was less to get wrong. Managed auth, managed , static hosting, functions — every choice removed a category of code the AI could break on our behalf, and a category of thing we'd have to maintain.
- Obstacles were solved by feeding the AI exact evidence — the literal error, the actual code, the config, the real symptom — and by scoping fixes narrowly so working code stayed working. Twice the symptom was in the code but the cause was in the infrastructure.
- Launch meant a real test against reality: a live purchase (and a declined one), a second user account, an on-demand trigger, a deep link on the deployed site. Not "it compiled."
You don't need a big idea to start. You need a small one, a one-paragraph spec, and the willingness to direct rather than to type — and the patience to test the thing against reality before you call it done.