Spec first, then code

The most useful thing I do on any project happens before I open the editor: I write the spec.

Not a fifty-page document. A page, sometimes two. What am I building, for whom, and what does "done" look like. What is explicitly out of scope. The few decisions that everything else hangs on.

Why it works

Code is an expensive place to think. Every idea you explore in code costs real time, and once it exists you are reluctant to throw it away. Prose is cheap. You can rewrite a paragraph ten times in the time it takes to refactor one component.

So I do the hard thinking where thinking is cheap. By the time I am writing code, the interesting questions are already answered, and implementation becomes almost mechanical — in the good way.

What a spec catches

• The feature you thought was simple but has four edge cases.
• The two requirements that quietly contradict each other.
• The thing you were about to build that nobody actually needs.

That last one is the real payoff. The cheapest feature is the one you talk yourself out of before you build it.

It is not waterfall

Writing a spec first does not mean freezing it. The spec is a draft of your intent, and intent changes as you learn. I edit it while I build. But starting from a written intent means every change is a deliberate decision instead of a drift you only notice later.

A spec is not a contract with the future. It is a conversation with yourself about what you actually mean.

When you build solo this matters even more. There is no one to talk it through with, so the document becomes the other half of the conversation. I have shipped Zirva, Foundrr, and Fridgit this way, and the pattern holds every time: clarity first, and the code follows.