Claude Code + Claude Design: A Friendly Guide to Shipping Apps That Are Actually Good

Here is the pattern we see every week. Someone opens Claude Code on a Friday, describes an app, and by Sunday night they have something that runs, looks decent and genuinely works. It feels like magic, because it more or less is.

Then Monday arrives. They add the second feature and the first one breaks. The design drifts, because screen four was generated three days after screen one and nobody wrote down what a button looks like. Nothing has tests. Nobody can explain why the auth flow works, only that it does. The prototype took two days; the last 20% is now four months and counting.

This is not an argument against AI-assisted development. We build with Claude Code on every client engagement and we would not go back. It is an argument for using it the way it actually wants to be used. What follows is the workflow our team uses, written as a walkthrough you can copy, followed by an honest section on the parts that still need a person with a decade of scar tissue.

The 2026 Stack, In One Paragraph

Claude Design arrived in research preview in April 2026. You point it at your codebase and brand files, it derives a design system from them, and from there prompts, screenshots or captures of live sites turn into real interactive prototypes with your colours, type and components applied consistently. You refine by chatting, commenting on specific elements, editing text inline or nudging sliders. When you are happy, it packages a handoff bundle for Claude Code.

Claude Code is the agentic half: it reads your repo, writes code, runs commands, reads the output and iterates until a check passes. Together they close a loop that used to contain three handoffs and a Slack thread.

That loop is the good news. The bad news is that a closed loop with no verification inside it simply produces confident nonsense faster. So here is the workflow.

Step 1: Let Claude Interview You Before It Builds Anything

The instinct is to describe your app in one paragraph and hit enter. Resist it. The highest-leverage move in this entire workflow costs about fifteen minutes: make Claude ask you the questions first.

Prompt — copy thisI want to build [one-line description]. Interview me in detail
using the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns
and tradeoffs. Don't ask obvious questions - dig into the hard
parts I might not have considered.

Keep interviewing until we've covered everything, then write a
complete spec to SPEC.md.

You will be asked things you had not thought about: what happens when two users edit the same record, what the empty state says, whether an admin can impersonate a user, what happens on a refund. Answer them now, in a text file, rather than in month three, in production.

Then start a fresh session to build. The interview session is full of your deliberation; the implementation session should start clean with only the spec. A good spec names the files and interfaces involved, states what is explicitly out of scope, and ends with an end-to-end check that proves the feature works.

Step 2: Design the System, Not the Screens

This is where most AI-built apps quietly fall apart, and it is a design problem rather than a code problem. Generate screens one at a time and you get twelve slightly different buttons, five spacing scales and a colour that is nearly your brand colour on nine of them.

Claude Design is built to prevent exactly this, if you set it up properly. During setup it reads your codebase and design files to derive the system, so spend the time getting that right before generating a single screen. Define your palette, type scale, spacing rhythm, component states, and the boring ones everybody skips: focus rings, disabled states, error states, loading states, and what a 400-character name does to your card layout.

Step 3: Write a CLAUDE.md Short Enough to Actually Be Read

CLAUDE.md is the file Claude reads at the start of every conversation in your project. Run /init to generate a starter from your codebase, then edit it down hard.

The counter-intuitive rule: a long CLAUDE.md is worse than a short one. When the file is bloated the important rules get lost in the noise, and Claude starts ignoring them. For every line, ask whether removing it would cause a mistake. If not, delete it.

CLAUDE.md — the shape to aim for# Commands
* Dev: pnpm dev  |  Test: pnpm test  |  Typecheck: pnpm typecheck
* Run single tests, not the whole suite, unless asked

# Code style
* ES modules, named exports, no default exports
* Design tokens only, never raw hex values

# Workflow
* Typecheck after any series of edits
* Branches: feat/*, fix/* - never commit straight to main

Include commands Claude cannot guess, style rules that differ from the defaults, testing instructions, branch etiquette, environment quirks and genuine gotchas. Leave out anything Claude can work out by reading the code, standard language conventions, and self-evident advice like “write clean code.” Keep it in git so the whole team improves it.

For knowledge that is only relevant sometimes — your API conventions, your release checklist, your design token rules — use skills instead. A SKILL.md in .claude/skills/ loads on demand rather than taxing every single conversation.

Step 4: Explore, Then Plan, Then Code

Letting Claude start coding immediately is how you get a beautifully implemented solution to the wrong problem. Use plan mode to separate thinking from doing.

Skip the plan for anything you could describe in one sentence: a typo, a log line, a rename. Planning earns its overhead when the change touches several files, when you are unsure of the approach, or when you do not know the code well.

Step 5: Always Give Claude a Way to Check Its Own Work

Claude stops when the work looks done. With no check available, “looks done” is the only signal it has, and you become the verification loop, catching every mistake by hand. Give it something that returns pass or fail and the loop closes itself: it works, runs the check, reads the result, iterates.

The check can be a test suite, a build exit code, a linter, a script that diffs output against a fixture, or a browser screenshot compared against the design. That last one matters enormously for design fidelity.

Weak vs strong prompts✗  make the dashboard look better

✓  [paste design] implement this. take a screenshot of the result,
   compare it to the design, list the differences and fix them.

✗  the build is failing

✓  the build fails with: [paste error]. fix it, verify the build
   passes, address the root cause - do not suppress the error.

And ask for evidence rather than assertions: the test output, the command it ran, the screenshot. Reading evidence is far quicker than re-running the verification yourself.

Step 6: Use Subagents for Research and Fresh-Eyes Review

Context is the fundamental constraint. Everything Claude reads fills the window, and performance degrades as it fills. Subagents run in their own separate context and report back a summary, which keeps your main conversation clean.

Use them two ways. First for investigation: “use subagents to investigate how our auth handles token refresh and whether we already have OAuth utilities to reuse.” Second, and more valuable, for review. A reviewer in a fresh context sees only the diff and your criteria, not the reasoning that produced the change, so it judges the result on its own terms instead of being charmed by its own work.

Adversarial review promptUse a subagent to review the diff against SPEC.md.

Check that every requirement is implemented, that the listed edge
cases have tests, and that nothing outside scope changed.

Report gaps that affect correctness or the stated requirements -
not style preferences.

One caveat worth knowing: a reviewer asked to find gaps will usually find some, even in sound work, because that is what you asked for. Chase every finding and you end up with defensive code, needless abstraction and tests for impossible cases. Scope the reviewer, then apply judgement to the output. Which, you will notice, requires someone capable of judgement.

Step 7: Manage the Session Like a Professional

Most of the bad output we see traces back to a cluttered session rather than a weak model.

The Five Failure Patterns, And Their One-Line Fixes

So Why Still Hire a Developer and a Designer?

Because every single practice above is a judgement call, and the tools do not make judgement calls. They execute them beautifully, and at remarkable speed.

Look back at the workflow. Someone had to know which questions in that interview actually mattered. Someone had to decide the spacing scale, and that the destructive action needs a confirmation while the archive action does not. Someone had to choose an architecture that survives feature nine. Someone had to look at a green test suite and recognise that it was testing the wrong thing. Claude will happily write the test you asked for, including when the test you asked for is wrong.

Then there is the expensive, unglamorous work that never shows up in a weekend demo: performance budgets, accessibility beyond the automated checks, a security review of the auth path, data modelling you will not regret at scale, error handling and observability, and a migration plan for the schema you will inevitably change. None of it is exciting. All of it is the difference between a prototype and a product.

And design is not decoration. Taste is a judgement about your users, your market and your brand, formed by having watched real people fail to use real interfaces. A tool can generate a hundred attractive layouts in an afternoon. Choosing the right one, and knowing why the other ninety-nine are wrong for this audience, is the job.

What has genuinely changed is the ratio. Our engineers write far less boilerplate and spend far more time on decisions that need experience. Output per person is up sharply; the need for experienced people has not moved. If anything, directing these tools well is itself a senior skill: it compounds with judgement and it is very hard to fake without it. We wrote more about that shift in Lessons from Building Production Apps with Claude Code, and if you are still choosing tools, our Claude vs. Copilot vs. Cursor comparison covers which fits which job.

Your Weekend Checklist

Work through that list and you will get further, faster, and with far fewer Monday-morning surprises than almost anyone building this way today. Where it stops working is exactly where it always stopped working: at the point where the question is no longer “how do I build this” but “is this the right thing to build, and will it still be right in two years?”