Vision Over Syntax: I Design the Entire Product in My Head Before the First Commit

Every product I have shipped began the same way: not with npm create, but with days of thinking until I could see the entire system — the data's journey, the trust boundaries, the failure modes, the cost curve — before writing a single line. Syntax is a solved problem in 2026. Vision is not. This post is about the part of engineering that no model generates for you.

The whiteboard test

Before I opened an editor for Sable, my finance agent, I could answer these on a whiteboard: Where does the data live? (On-device SQLite — nowhere else, ever.) What is the model allowed to do? (Propose, never commit.) What happens when two writes collide? (A queue serializes them.) What does day 30 look like for the user? (A morning briefing that reads their real numbers.) When you can answer questions like these before coding, the build becomes transcription. When you can't, no amount of generated code will save the product — you will just arrive at the wrong destination faster.

Architecture is a set of refusals

The strongest decisions in my products are the things they refuse to do. streamerOS refuses to send chat data to a server — it ingests Twitch and YouTube directly on the user's machine. Sable refuses to let the LLM mutate the database — every write passes a human Review & Confirm gate. The blog pipeline refuses to own a CMS, a database, or a server — its state is the Git history. Each refusal deleted an entire class of cost, risk, and maintenance from the product's future.

Junior engineers add capabilities. Architects delete futures. Every "no" made early is a pager that never goes off, an invoice that never arrives, a breach that never happens.

Why this matters more than ever

AI collapsed the cost of implementation to near zero — which means the value of knowing what to implement has gone vertical. Two engineers with the same Claude subscription will produce wildly different outcomes, and the difference is entirely in the quality of the questions they ask before generating anything. My job, as I practice it, is to be the person in the room who has already thought three layers deeper than the ticket: not "build the export feature," but "what schema makes exports free forever?"

How I run the thinking phase

• Write the data contract first. One authoritative schema. Every layer — DB, API, UI, even the AI's structured outputs — is generated to satisfy it.
• Name the trust boundaries. Who can do what, and what can the model never do? These lines are drawn before the first prompt, because they are unpromptable.
• Price the architecture. Every design gets a cost model — tokens, storage, compute — before it gets code. A design that doesn't know its own unit economics is a demo.
• Only then, orchestrate. With contracts, boundaries, and costs fixed, Claude fills the layers at a speed no team can match — because there is nothing left to be ambiguous about.

Recruiters read a hundred résumés that say "proficient in React, Node, TypeScript." Fine — so is the model. The question worth asking a candidate is: show me a system you refused to build the easy way, and what that refusal bought. I have five answers deployed.