Build an MVP with Claude Code
AI Development

How to Build an MVP with Claude Code: The Six-Week Shape That Actually Ships

8 min read | Engineering Strategy

Claude Code changed how fast an MVP gets built. It did not change what an MVP is — and that is the mistake we watch teams make over and over. Given a tool that produces working software this quickly, the instinct is to build more. The teams that ship build less, faster, and spend the reclaimed time on the parts that were always hard.

This is the six-week shape we use for a Claude Code MVP: what happens each week, what gets deliberately cut, and the four decisions that determine whether week six ends in a launch or in the 80%-built, 0%-shipped trap.

Week 0
Spec & scope · one sentence per screen
Weeks 1–2
Spine · auth, data model, deploy
Weeks 3–4
The one flow that matters
Weeks 5–6
Hardening · tests, edges, launch

1. Week Zero: Scope Is Still the Whole Game

The single highest-leverage hour in a Claude Code MVP happens before any code exists. Write the spec — not a feature list, a spec. One document that states the problem, names the one user journey that must work, and lists every screen with a single sentence describing what it does.

Then cut it. An MVP that takes six weeks with Claude Code would have taken four months without it, which means the temptation is to scope four months of product. Resist. The constraint that matters is not build time; it is how much surface area you can verify, support and iterate on. Every extra flow is a permanent tax on every future release.

The scoping test

If you cannot describe the MVP’s core loop in one sentence — “a clinic admin invites a patient, the patient books, both see the same appointment” — you do not have an MVP, you have a roadmap. Cut until the sentence exists.

Week zero also produces the project’s context file. In Claude Code this is CLAUDE.md: stack, conventions, directory layout, commands to run tests, things never to touch. Ten minutes writing it saves hours of correcting drift later, and it is the artefact your next developer will thank you for.

2. Weeks One and Two: Build the Spine, Not the Screens

The order most teams get wrong. Screens are the fun part and the fast part, so they get built first — and then auth, data modelling and deployment turn out to contradict half of them.

Build the spine first: authentication and roles, the data model, one deployed environment with CI running. Ugly, unstyled, real. This is exactly the work Claude Code is best at — well-specified, mechanical, heavily conventional — and it is also the work where a wrong decision is most expensive to reverse.

1
Data model before UI
Have Claude Code propose the schema from your spec, then review it yourself, line by line. This is a business-logic decision wearing a technical costume.
2
Auth and roles on day two
Retrofitting permissions into a built product is one of the few genuinely miserable refactors. Do it while there are four files.
3
Deploy something on day three
A hello-world page in staging, with CI/CD wired. If deployment is not proven in week one it will ambush you in week six.
4
Tests from the beginning, not the end
AI makes test-writing close to free, which removes the last honest excuse. A suite that runs on every push is what lets you move fast in weeks three to six.

3. Weeks Three and Four: One Flow, Properly

Now build the journey from your one-sentence core loop — end to end, including the unhappy paths. Not five flows at 70%. One flow at 100%.

This is where working in plan mode earns its keep: have Claude Code lay out its approach before it writes anything, read the plan, correct the two things that are wrong, then let it execute. The correction takes ninety seconds and saves an afternoon of unpicking. Parallel subagents handle the wide, shallow work — generating the test suite while the main thread builds the feature — and we walk through that mechanic in detail in our guide to shipping with Claude Code and Claude Design.

Two rules we hold to in this phase:

🔁
Never accept code you have not run
Not “read” — run. The failure mode of AI-written code is confident plausibility. The test suite and the browser are the only reliable arbiters.
🧩
One change per verification loop
Big multi-feature prompts produce big multi-feature diffs that nobody reviews properly. Small loop, run tests, commit, repeat.
🚧
Unhappy paths are part of the flow
Expired session, duplicate submit, empty state, network failure, wrong role. Ask for these explicitly — they are rarely produced unprompted.
👤
A human owns the architecture
Claude Code will happily implement a design that will not survive your second thousand users. It optimises for the request, not the roadmap.

4. Weeks Five and Six: The Part That Decides Everything

Two full weeks — a third of the project — on work that adds no features. Teams cut this first and regret it every time.

Week 5
Edge cases, error states, empty states, loading states
3 days
Week 5
Security pass: authz on every endpoint, input validation, dependency audit
2 days
Week 6
Performance and mobile: real devices, real network conditions
2 days
Week 6
Monitoring, error tracking, analytics on the core loop
1 day
Week 6
Handover docs, runbook, launch
2 days

The security pass deserves particular attention with AI-assisted code. Veracode’s benchmark testing found 45% of AI-generated code samples failing OWASP Top-10 categories, and authorisation checks are a recurring gap — an endpoint that works correctly for the user it was written for and leaks for everyone else. Enumerate every endpoint and confirm the role check explicitly. Do not assume.

5. What Actually Changes, and What Does Not

Claude Code compresses
Boilerplate & scaffoldingHours → minutes
Test suitesDays → hours
Multi-file refactorsWeeks → days
Docs & runbooksNever → same day
Codebase onboardingWeeks → hours
Claude Code does not compress
Deciding what to buildUnchanged
Architecture judgmentUnchanged
User researchUnchanged
Security reviewSlightly heavier
Stakeholder alignmentUnchanged

That right-hand column is the answer to why AI-assisted MVPs still need a senior engineer, and why a six-week build still needs a real brief. If you are commissioning this rather than building it, how to brief an app development agency covers the input side, and our lessons from production Claude Code work covers where the tool has genuinely surprised us — in both directions.


Six weeks, one core loop, shipped.

Tell us the sentence that describes your product’s core loop. We will come back with the six-week shape, what we would cut, and what we would refuse to rush.

Start the Conversation →

Engineering Insights

Latest from Syntaxa Studio.

Loading latest posts