Start on paper

AI tools changed how we build apps and sites at MonoBlock. Claude Code has made our lives easier, and it has also shown us how much worse the result gets when you use it badly. Most people open Claude Code and start typing, and that is where it goes wrong.

What comes out depends on how much thinking you did before you opened the laptop. An agent will build whatever you describe, at speed, and it has no way of knowing you hadn’t actually decided yet.

So here is the pipeline I use. Every step moves a decision earlier, to the point where changing your mind is still free.

Pen and paper, with the laptop shut.

Paper forces you to slow down. A prompt lets you stay vague: “a gallery page with albums” is a perfectly acceptable sentence and a completely useless instruction. A pen won’t let you get away with it. You have to put the back button somewhere. You have to draw the screen with one photo on it, then the screen with two hundred, then decide what sits there when the list is empty and what the user sees when an upload fails.

Those are the parts that eat your time later. Prompting pulls you toward describing the beautiful bits; sketching drags the edge cases out of you on day one, when fixing them costs nothing but an eraser. The sketches can be ugly. Each one just has to settle something.

Now move into a design tool like Claude Design or Paper, and feed it everything you have: photos of the sketches, competitor screens, products whose interfaces you admire, and specifically what you want from each reference and what you don’t.

You are designing a flow. It’s easy to end up with a dozen beautiful screens that don’t connect to each other. Work end to end: how does someone get in, what do they see first, how do they reach the thing they came for, and how do they get back out again.

Every screen needs a route in and a route out. A screen with neither is a poster.

This is also where you decide the user experience. Nobody fixes a confusing navigation model during the build. They just build the confusing navigation model.

Ask Claude Design to turn the designs into a working prototype. You get back a zip of HTML files you can open in a browser and click through: every screen, wired to every other screen. It’s the cheapest test you will ever run.

Reading a flow in a design file and walking through it with your thumb are completely different experiences. A navigation model that looked obvious as a diagram turns out to dead-end three taps in. A tab bar you were confident about turns out to bury the one thing people actually want. You find those in ten minutes of clicking, and the fix is moving a box in a design file.

Hand it to someone else, too, and say nothing. Watch where they hesitate. That hesitation is the only honest feedback you’ll get before launch.

When the designs are settled, export them for handoff, and make sure the export includes screenshots as well as the written instructions.

Written specs get interpreted, and images don’t. When Claude Code has the actual picture of a screen sitting next to the description of it, you stop losing time to corrections about things that were always in the design and simply didn’t survive translation into prose.

What you want at the end of this step is a single zip: the instructions, plus the images.

Give the zip to Claude Code, and be explicit that you don’t want anything built yet:

Then read the reply properly, because it is the last cheap checkpoint you get.

Two different things get caught here. The first is a misreading: it has described a screen as doing something it doesn’t do. Correct it now and you’ve saved an afternoon. The second is a gap: it describes everything accurately, and in reading it back you realise nobody ever designed the empty state, or the error, or what happens after the final step. The read-back is doing its job when that happens.

Skipping this step is expensive, because an agent will always produce something. If it has misunderstood the brief it will misunderstand it fluently, for hours, across dozens of files, and the result will look finished. Two minutes of reading prevents that.

Only now do you tell it to start.

Work in small passes, and look at the thing after each one. Don’t hand over a paragraph of features; hand over a screen at a time and open the app. The good prompts at this stage read like bug reports, the same sentence you’d say out loud if you were sitting next to someone:

Each one comes from actually using the thing. You’re reporting what you see.

Every so often, go back to the source:

The zip is both the spec and the test suite. Use it at the start to prevent the wrong build, and use it during the build to catch the drift.

And when you find yourself correcting the same thing twice (a constraint of your stack, a file that must not be hand-edited, a deploy that works differently than it looks), stop correcting it and write it into CLAUDE.md instead. Write the rule with its consequence attached, because a bare “don’t do X” gets rationalised away the moment X looks like the obvious path.

A screenshot of a screen is not proof that the screen works.

Run it on a real device. If it’s a web app, give the agent a live account and let it click through the actual flow: buy something with a test coupon, sign up as a new user, break it on purpose. If the app does something that needs two people, plug in two phones and test it with two phones.

If a bug only appears with real hardware and real data, a test without real hardware and real data has proved nothing at all.

Before launch, fan out. This is the one place where running several agents in parallel genuinely pays: point them at the finished app and have each one hunt a different class of problem: security, performance, SEO, accessibility, broken user flows.

Parallelism is good for breadth. Five agents building five parts of one feature will produce five different opinions about what the feature is. Audit in parallel, and build in one thread where you can watch.