Stop one-shotting your app

A frontier model can build your whole app in one prompt. Sometimes that's even true: you describe the thing, you wait, and a working app falls out the other side.

The question is whether you should. And no, you shouldn't.

Not because the model isn't good enough. Because one-shotting skips the part of building that actually matters.

One-shotting skips the part that matters

When the whole app lands at once, you never see it come together. You go straight from idea to finished thing, with no stops in between.

And the stops are where the real work happens.

Every time you see a piece of the app working, use it, and react to it, you learn something you couldn't have known before. This flow is clunky. That label is wrong. I forgot a whole state this feature needs. Those reactions are the build. One-shotting trades all of them for speed you didn't actually need.

You don't get a better app by generating it faster. You get a better app by seeing it, using it, and correcting course before the next layer goes on top.

Build in milestones instead

So break the roadmap into milestones. Each one is one or two key features, no more.

Sequence them by dependency, because the order isn't optional. You can't build invoices before you've built the users and clients those invoices belong to. Lay the foundation, then build on it.

Then after each milestone, stop and run a round of rapid-fire refining:

• Use the feature you just built, for real.
• Fire off quick prompts to fix the small stuff and tighten the UX.
• Only then move to the next milestone.

Each milestone is a checkpoint, not just a delivery. You're not slowing down to be careful. You're building on ground you've actually tested instead of ground you assumed.

The thing that needs fixing is usually your plan

When something's wrong after a milestone, it's rarely a Claude bug.

The vast majority of the time, I planned it wrong. I missed a detail I couldn't have seen until I used the app.

Real example. I was building invoices, and I'd scoped the status field as draft or sent. Simple enough. Then I started using it, and the gaps showed up fast: I also needed pending, past due, deferred, re-negotiated. None of that was in my plan. The model built exactly what I asked for. What I asked for was incomplete, and I only knew it once I could click around in the real thing.

That's the case for milestones in a single example. A checkpoint is where you catch your own planning misses, while they're cheap, before the next three features get built on top of the wrong assumption.

One-shot the whole app and that miss is buried under everything else by the time you find it.

Milestones keep you in the loop

So stop seeing milestones as the model's limitation, the thing you do because the AI can't quite handle the whole job yet.

They're the opposite. They're how you stay in the loop. Checkpoints beat one big bang, every time, because checkpoints are where your judgment gets to do its work.

Shipping software was never a code-generation speed contest. It's a sequence of decisions you can only get right once you see the thing working.

Stop one-shotting your app. Build it in milestones, and refine at every one.