The 4-week MVP playbook we use

A four-week MVP is not a sprint. It is a sequence of decisions that, made in the right order, compound into a launched product.

Most teams that try this fail at the same two moments. They start building before the scope is locked, and they discover the boring infrastructure work in week three when it is already too late. This is the playbook we run to avoid both.

Pre-week zero: the call

Before the clock starts, we run a 30-minute discovery call and a 48-hour scoping pass. Output: a one-page scoped proposal with a fixed scope, a fixed price, a fixed timeline, and the three things we will not be building. If the scope is wrong, the rest does not matter. We say no to features here so we can say yes to shipping later.

The most common mistake at this stage is treating "MVP" as "everything, but smaller." It is not. An MVP is the smallest product that answers the riskiest open question. Usually that is "will users use this at all." Everything else - settings pages, edge cases, multi-tenancy, role-based permissions - is post-launch work, even if it ends up shipping the next week.

Week 1: design + spine

• Days 1-2: User flow on paper. Three to five flows, no more. We name the one flow that is the product, and we make sure it is two clicks shorter than the user expects.
• Days 3-4: Design system. Type scale, color, spacing, component primitives. Boring discipline now buys us speed in week three.
• Days 5-7: Spine of the app. Routes, auth, database schema, deploy pipeline. Nothing is interactive yet. The point is that by the end of week one, a deploy goes from git push to a live URL in under three minutes. If it doesn't, week three is going to be ugly.

By Friday of week one you can click through the product's empty rooms. That is what we demo.

Week 2: the one flow that is the product

Build the core flow end-to-end - frontend, backend, persistence, the works. Cut every corner that is not on the critical path. Auth uses a hosted provider. Email uses a transactional service. Payments use Stripe or Razorpay's hosted checkout. Search is WHERE ... ILIKE ... until it cannot be. Every "we should generalise this" is filed in a backlog and ignored for now.

The output of week two is one flow that works for one user, in one happy path, on one device. It is ugly at the edges. It works.

Week 3: AI + the second flow

This is where most studios get distracted by the AI features and forget the rest of the app. Our rule: AI features ship behind the same UI primitives as everything else, on the same infrastructure, with the same observability. No special snowflake stack.

• If there is RAG, the retrieval pipeline ships with an eval set on day one.
• If there is an agent, it has a fallback path the moment it errors.
• If there is a voice agent, it has a transcript log and a human-handoff button.
• LLM costs and latency dashboards exist before launch, not after the first invoice.

The second user flow gets built in parallel. By Friday of week three, the product does the one thing it is for, plus the next-most-important thing. Nothing more.

Week 4: harden + launch

• Days 22-24: Polish - mobile pass, empty states, error states, the seven UI bugs you knew about and ignored.
• Days 25-26: QA, accessibility pass, performance pass. LCP under 2.0s on a mid-range Android, or we do not launch.
• Day 27: Soft launch to ten users. Watch what they actually do. Patch what breaks.
• Day 28: Public launch. Product Hunt, X, LinkedIn, the founder's network.

We hand over a repo you own, infra you own, credentials you own, and a written runbook for everything that runs in the background. Thirty days of bug fixes and small iteration are included. After that, retainer or part ways.

The trade-offs we make on purpose

A four-week MVP comes with constraints. We are honest about them upfront:

• No native iOS or Android in four weeks. PWA only. Native ships in months six to nine when it is justified.
• No custom design system unless the product itself is the design (a brand site, a launch microsite). Tailwind + a clean primitive library for the rest.
• No premature optimization for scale. We engineer the product to handle 10,000 users cleanly. Past that, we re-architect at the inflection point, not before.
• No internationalization, no white-labeling, no role-based access matrix, no "future-proofed plugin system." All are post-launch work.

These are not corner-cutting. These are the difference between a launched product and a half-finished project.

What four weeks is not

Four weeks is not enough for: a regulated fintech product, a multi-sided marketplace with critical mass concerns, a hardware-software combo, a product that depends on bespoke ML model training, or anything where the riskiest open question is technical research instead of user adoption. We will tell you on the discovery call.

If a four-week MVP is what your idea actually needs, book a call. We will scope it on the call and send a one-page proposal in 48 hours.