Stop Coding First: The Prototype Tax and the 4-Step Fix

Most people building with an AI coding agent start in the same place: they open Claude Code, describe the app they want, and let it generate a working build. It feels productive — you have running software in an afternoon. Then the real cost shows up. The flows are wrong, the screens you imagined don't match what users need, and you spend the next three weeks rebuilding code that was never the bottleneck. The bottleneck was the thinking, and you skipped it.

There is a name for that hidden cost: the prototype tax. You pay it every time you ask code to figure out a product decision that should have been settled before any code existed. Writer-builders Ashwin Francis and Raghav Mehra described the pattern in their May 2026 Cash & Cache essay, "A Weekend in Claude Design Saves 3 Weeks of Claude Code," and the title is the whole argument: design and test the full experience first, so your coding agent builds the right thing once.

This guide turns that idea into a method you can actually run as a solo builder. It is a four-step loop — define, prototype, inspect, test — that front-loads every product decision into a fast design phase before Claude Code ever touches a file.

Why coding first is the expensive path

A coding agent is extremely good at one thing: turning a clear specification into working software. It is structurally bad at a different thing: deciding what the software should be. When you start in code, you are forcing the agent to make hundreds of product and design decisions implicitly, buried inside implementation choices you can't see or compare.

That's why the rebuild is so costly. Changing a design idea in a prototype is a sentence. Changing the same idea after it's been implemented means untangling state, data flow, components, and styling that were all built around the wrong assumption. The weekend-versus-three-weeks framing isn't hyperbole — it's the difference between editing a sketch and demolishing a finished room.

The fix is to move every decision you can into a cheap medium first. Here is the loop.

Step 1: Answer six questions to turn a vague idea into one prompt

Before you generate anything, force your fuzzy idea into a single, specific prompt by answering six questions in a few lines each:

1. Context  — What situation is the user in when they reach for this?
2. Audience — Who exactly is this for? (Be narrow, not "everyone.")
3. Core job — What is the one job the product must do well?
4. Screens  — What are the few screens needed to do that job?
5. Brand    — What look and tone fits this audience?
6. Output   — What format is the deliverable? (Web app, mobile, dashboard…)

The point of this step is discipline, not paperwork. If you can't answer "core job" in one sentence, you don't understand the product yet — and no amount of code will rescue an idea you can't state plainly. Stitch your six answers into one paragraph. That paragraph becomes the prompt for the next step.

Step 2: Prototype in Claude Design

Take your prompt to Claude Design, Anthropic's design tool (launched April 17, 2026, powered by Claude Opus 4.7), and have it generate the screens. Claude Design is built for exactly this moment: you describe what you need, it produces a first version, and you refine through conversation, inline comments, direct edits, and adjustment controls until the look and the flow feel right.

You are not trying to ship pixels here. You are trying to see the whole experience — the screens, the transitions between them, the empty and loaded states — as something a person could click through. Iterate until the prototype represents the product you actually mean, not the first thing the model guessed. This is the cheapest place you will ever make these changes, so make them all here.

A practical tip for solo builders: keep your prototype honest about scope. If a screen exists only because it "might be nice," cut it. Every screen you prototype is a screen you'll eventually ask Claude Code to build.

Step 3: Run a PM-grade inspection

A prototype that looks good can still be quietly broken in the ways that matter. Step three is a 15-point checklist — a product-manager-grade inspection pass — that catches the gaps before users do. The source method organizes that pass around five core dimensions, each walked screen by screen — which is how a handful of named categories becomes roughly fifteen concrete sub-checks in practice. The five dimensions it calls out specifically:

• Visual hierarchy — Does the eye land on the most important thing first? Is the primary action obvious on every screen?
• Empty states — What does each screen look like with no data yet? (This is the first thing a new user sees, and it's the most commonly forgotten.)
• Error states — When something fails or input is invalid, does the screen say something useful, or does it just break?
• Copy voice — Does the text sound like one consistent product, in language your specific audience uses?
• Accessibility — Can someone navigate with a keyboard, read the contrast, and understand the screen without relying on color alone?

Walk every screen against each dimension. The discipline here is to inspect like a skeptical product manager reviewing someone else's work, not like the proud creator of your own. Anything you'd flag in a stranger's product, flag in yours. Fix what you find in the prototype — still cheap, still just edits.

Why this step earns its keep: empty states, error states, and accessibility are exactly the things a coding agent will not invent for you unless you specify them. Catching them in design means they become part of the spec instead of a fourth-week surprise.

Step 4: User-test against the viability rubric

A prototype you can click is a prototype you can test — without writing code. Put it in front of 5 to 20 testers and score their reactions against a simple viability rubric with two parts.

Demand indicators (would anyone actually want this?):

1. Would they pay for it — and at what price?
2. Would they share it with someone else?

Intuitiveness signals (can they actually use it?):

1. Did they understand what the product does within about 10 seconds?
2. Did they need help navigating or figuring out a feature?
3. What did they suggest for the core functionality?

Then read the result against three verdicts:

• Strong demand + clear design → build it. Hand it to Claude Code with confidence.
• Strong demand + fuzzy design → refine and retest. The idea is good; the experience isn't ready. Loop back to Step 2.
• Weak demand → kill it. This is the most valuable outcome of the whole method. You just saved three weeks of building something nobody wanted, and it cost you a weekend.

That last verdict is the entire point. The prototype tax is worst when you only discover weak demand after you've built the product. Testing a prototype lets you get the kill signal while it's still free.

Applying this as a solo builder

The four-step loop was written with teams in mind, but it adapts cleanly to a solo builder — you just play every role yourself, deliberately.

• You are the PM in Step 3. Schedule the inspection as a separate session from the design work, ideally a day later, so you're reviewing with fresh, critical eyes instead of defending choices you just made.
• You don't have a research panel for Step 4 — borrow one. Five testers is enough to expose the obvious problems. Use a few people from your target audience, a relevant community, or even a single sharp friend who'll tell you the truth. The 10-second comprehension test works with an audience of one.
• Treat the kill verdict as a feature, not a failure. A solo builder's scarcest resource is time. A method whose most common honest output is "don't build this" is protecting the exact thing you can't get back.

Concretely: say you want to build a habit-tracking app. Coding first, you'd spend days on auth, a database schema, and a streak algorithm before realizing the daily-entry flow is too tedious to use. Designing first, you'd prototype the daily-entry screen in an hour, watch three testers fumble it in Step 4, and learn that the whole concept lives or dies on that one interaction — before writing a single migration. Same lesson, one-twentieth the cost.

The handoff: from Claude Design to Claude Code

The reason this workflow is more than good advice is that the tools now connect directly. When a Claude Design prototype passes the rubric, Claude Design packages it into a handoff bundle for Claude Code to implement — design-to-build in a single instruction. The prototype isn't a throwaway artifact you describe to your coding agent in a lossy paragraph; it is the spec. Every decision you made and tested in the cheap medium travels intact into the build.

That's what closes the loop. You front-load the thinking where changes cost a sentence, validate it with real people before committing engineering time, and only then spend your coding agent's effort — once, on the right thing.

Bottom line

The prototype tax is the cost of asking code to make decisions that belong in design. The four-step fix — define in six questions, prototype in Claude Design, inspect against a 15-point PM checklist, and test against a demand-and-intuitiveness rubric — moves those decisions to the cheapest possible place and gets you a build/refine/kill verdict before you write any code. For a solo builder counting time as the real budget, a weekend spent here genuinely is cheaper than three weeks spent rebuilding.

Source: Ashwin Francis and Raghav Mehra, "A Weekend in Claude Design Saves 3 Weeks of Claude Code," Cash & Cache, May 2026. Claude Design details from Anthropic Labs.