Building without a finished spec

I didn't build Cherry from a product requirements document. There was no finished specification, no carefully diagrammed architecture, no master plan waiting to be translated into code. There was a problem I couldn't stop thinking about — companies drown in customer feedback, and the part worth acting on is buried in the noise — and a blank Claude Code session. I began with the problem, used the model to explore possible structures, and iterated until the specification emerged from the work. I want to be clear that this wasn't confidence. I started with conversation because I didn't know what to build yet.

The spec emerged through building

The clean story of software goes: think first, specify second, implement third. Some work happens that way. Zero-to-one work mostly doesn't, because when the problem is new, building the solution is how you learn what the problem contains.

Cherry began as "collect and summarize customer feedback." That framing collapsed within days. Summarization was easy. Trust was hard. The model could hand me five beautifully written themes, each with a persuasive explanation, and the fluency told me nothing about whether those themes were real, representative, distinct, or worth acting on. Every product question that ended up mattering came out of that gap. Should severity and reach be one score? (No — a problem can be devastating for a small group without being widespread.) Should a big customer automatically move an issue up? (No — revenue at risk should be its own visible dimension, never a hidden thumb on the scale.) Do twenty similar reviews mean twenty people? (Maybe. Or bots, or one influential complaint echoing.) What about the customers who never appear in the evidence at all? (Silence is a coverage gap.) And what happens after an issue is identified — because a feedback system that produces a beautiful dashboard nobody owns is a museum of customer frustration.

None of that was in my head on day one. It emerged through a loop: I'd bring an unfinished thought, Claude would propose an approach, I'd probe it, and somewhere in the probing I'd discover I had been asking the wrong question. Revise, implement a piece, watch what happened, find the next question. The specification exists now — but it's an output of the building, and it could never have been an input.

Judgment moves up the stack

There's a recurring anxiety about AI-assisted creation: if the model generated much of the code, who really built the product? I understand the question. I think it defines "building" too narrowly.

Someone still has to decide which problem is worth solving, which user the system serves, what output is misleading, which tradeoffs are acceptable, where a human must remain involved, what "good" means, and when the thing is finished enough to put in front of someone. The model doesn't eliminate those decisions. It makes them more important — because when implementation gets fast, it gets much easier to build the wrong thing well. A weak idea can become a polished interface before anyone pauses to ask whether the product should exist. A feature can feel inevitable simply because it was easy to generate. The discipline I've had to develop is asking, over and over: is this real functionality, or product theater? Are we solving the problem, or decorating it?

The scarce resource shifts from production to judgment. That's the whole change.

Propose and decide

Working this way often felt like working with a cofounder — someone I could bring a half-formed thought at any hour, who could hold the entire evolving system in context while we examined one tiny decision. The word overreaches, though. A cofounder owns outcomes. Claude doesn't wake up worried we chose the wrong customer, and it can't take responsibility for what ships. Thought partner is the honest term: it proposed, and I decided.

I've stopped finding the authorship question complicated. Directors don't operate every camera. Architects don't pour the concrete. Work becomes yours through sustained judgment across thousands of decisions and through taking responsibility for the result — and both of those stayed firmly on my side of the table. I chose the problem, kept asking the questions, rejected the ideas that felt impressive but hollow, and answered for what shipped.

Why I work this way

Arriving with a finished spec would have meant the model happily building my first idea — and my first idea was the summarization framing: plausible, and insufficient. Starting with the problem instead keeps me honest about what I don't know yet, and it keeps me open to better questions and better ways of working while the discernment stays my job. The loop is simple to describe: problem, conversation, possibility, challenge, prototype, observation, better problem. Thinking becomes interactive instead of private.

It has made me faster. The part I care about more: it has made me more curious. The unfinished space between an important problem and a product worth making is the most interesting place I've ever worked — and deciding what "worth making" means is still, and should stay, a human job.

How this philosophy shows up inside the product itself is its own essay: why the human stays in the loop.