Delivery

Anatomy of a 4-Week MVP

A 4-week MVP is not a smaller version of a 3-month MVP. It's a different process — one where the tempo is enforced from day zero and every decision is optimised for signal, not scope.

We ship working MVPs in 28 calendar days routinely. Not skeleton demos — logged-in, paying-customer-ready products with real backends, real UX and real QA. Founders and product teams frequently arrive at RedFin AI after being quoted 12–16 weeks by other agencies for the same thing. They usually think we're either cutting corners or making something up.

We're not. Here's the actual four-week map.

Week 0 — the pre-sprint that saves the sprint

The kick-off doesn't start on day 1. Roughly a week before, we run two structured 90-minute sessions:

• Session 1 — problem & users. Whose life gets better? Which decision gets easier? What behaviour changes when the MVP works? We leave with three user stories, ranked.
• Session 2 — scope & success. What's the smallest thing we can put in front of a user in 28 days that would tell us the top-ranked story is real? We leave with a written scope, a rough wireframe and — the important part — an explicit not-in-scope list.

The not-in-scope list is where the four-week timeline is actually earned. Every "wouldn't it be nice if" gets written down and deferred. Most of them turn out to be genuinely unnecessary once the MVP is live.

Week 1 — build the skeleton, prove the risky bits

Day 1 opens with the project already scaffolded — repos created, CI running, hosting set up, auth wired in, base UI components installed. This is where RedFin AI's AI-first pipeline earns its keep: what used to take a senior engineer three days now takes 90 minutes.

By end of Day 3, there's a deployed app with a login flow, a database, and a single working page. By end of Day 5, the riskiest technical bit — usually an integration, an AI model, or a novel algorithm — is prototyped, benchmarked, and de-risked.

Week 2 — the core user journey, end to end

The one journey the MVP has to demonstrate — signup → do the thing → get value — gets built end-to-end. Not polished. End-to-end.

By end of week 2 we have a demo that a real user can walk through unaided. It's ugly. There are missing states. Error messages are placeholder. The team resists the urge to fix any of that yet.

What matters: we run 3–5 user tests at this point, before we've spent any time polishing something that might be wrong. Almost every time, two or three assumptions turn out to be false. We course-correct with two weeks still in hand.

Week 3 — polish, edge cases, secondary flows

Now the app becomes actually usable. Real error states, empty states, loading states. The design gets a proper pass. Secondary flows — password reset, permissions, admin views — come in. Payments wire up. Analytics instrumentation.

This is where an AI-augmented team compounds. Every "boring but necessary" piece of code (form validation, list filters, admin CRUD, notification templates) is faster to generate with AI copilots than to look up a stackoverflow answer for. A week of what used to be tedious grinding becomes three concentrated days of review and refinement.

Week 4 — hardening, launch, handover

The final week is about making the MVP safe to release, not bigger:

• Days 1–2: Security review (auth, secrets, dependency scan, CSP, rate limiting). Load test. Backup and rollback rehearsed.
• Day 3: QA sweep across supported browsers/devices. Accessibility audit (WCAG 2.2 AA). Any P0 bugs fixed.
• Day 4: Production deploy. Monitoring live. Runbook written. Team walks through the app together, in production.
• Day 5: Client handover. Source code, credentials, docs, runbook. First real users invited in.

What we don't do

Everything above depends on a few equally important negatives:

• No custom design system in week 1. We use a strong off-the-shelf component library (Tailwind + shadcn/ui, Material 3, etc.) and customise the brand variables. Building a bespoke system pre-launch is a month of work for no user impact.
• No microservices. A single well-structured monolith will serve the MVP's first thousand users comfortably. Splitting comes when the load justifies it.
• No "we might need this later" abstractions. Every abstraction we build must earn its keep by being used at least twice. The rest is dead weight.
• No test coverage theatre. Automated tests cover the money paths (auth, payments, primary journey) and anything AI-driven. We don't chase 100%.

Where the 80% comes from

To be explicit — because clients ask us all the time — here's roughly how the time saving stacks up:

• ~30%: AI copilots on scaffolding, boilerplate, tests and admin CRUD.
• ~20%: Pre-built starter templates for common patterns (auth, teams, billing, permissions).
• ~15%: Aggressive scope discipline — the "not in scope" list.
• ~10%: Design-to-code automation from Figma.
• ~10%: AI-generated documentation, PR summaries, runbooks.
• ~15%: A senior-only team who don't need onboarding to the stack.

None of these individually would earn you an 80% speed-up. Together they compound.

When 4 weeks isn't enough (and we say so)

To be clear: not every project can or should ship in 28 days. Regulated fintech or health apps needing procurement-ready compliance documentation take longer. Deep ML systems needing custom model training take longer. Enterprise integrations across five stakeholder teams take longer.

If a 4-week MVP isn't right for what you're building, we'll say so on the intro call — before you've signed anything. But for most consumer apps, internal tools, AI-native SaaS and B2B point solutions, 4 weeks is not just possible. It's the right target.