How to launch an MVP in 6–12 weeks: the complete method

Launching an MVP in 6 to 12 weeks is realistic if you follow a concrete method: one week of discovery with ruthless scope cutting, three weeks to build the core flow end-to-end on production infrastructure, six weeks of iteration on real user signal, and a final stretch for handoff or continuity. What makes the difference is not coding faster — it's deciding better what not to build. At Freshwork we've been building software from Santiago, Chile for over 10 years — since 2014 — and this is the complete method we use in our MVP development projects.

What is an MVP — and what isn't it?

An MVP (minimum viable product) is the smallest version of your product that lets you validate, with real users, whether the problem you think you're solving actually exists and whether your solution works for them. It's software running in production, measuring real behavior. It is not a throwaway prototype or a polished deck for investors.

What it also isn't: a version 1.0 with "just the essentials" defined by committee. When every stakeholder adds their "must-have" feature, the 6-week MVP quietly becomes a 6-month project. Scope-cutting discipline is 80% of the method; the other 20% is executing fast and measuring everything.

What does the method look like, week by week?

Week 1: discovery and ruthless scope cutting

One week, not one month. You leave with three things: the core hypothesis written in one sentence ("users X will pay for Y because Z"), the minimum flow that validates it, and an explicit list of what will not be built. The rule is simple: if a feature doesn't help validate the core hypothesis, it's out of scope. It hurts — that's why we call it ruthless — but it's what makes everything else possible.

Weeks 2–4: the happy path end-to-end, in production

You build the complete happy path: from the moment a user arrives until they get value. No exhaustive edge-case handling, no settings screens, no polishing things nobody has used yet. And on production infrastructure from day one: real deployment, real domain, basic monitoring. "Production" doesn't mean over-engineering; it means that by week 4 you can send the link to a real user without cringing. Our internal rule: if by week four there's nothing you can click, something is wrong.

Weeks 5–10: iterate on real signal

This is where the MVP earns its name. Real users on the product, analytics recording what they do (and where they drop off), short conversations with early users, and weekly demos to decide the next step. Every week you prioritize based on what the data shows, not on a roadmap written before you had any information. You will learn things no planning session anticipated — that learning is the deliverable of this stage.

Weeks 11–12: handoff or continuity

Two possible exits. Handoff: documentation, training, and credential transfer to your internal team — the code is 100% yours, always. Or continuity: the same team moves on to the next phase. What matters is that the decision is made with six-plus weeks of real usage data, not gut feeling.

What should you cut — and what should you never cut?

You cut almost everything that doesn't validate the hypothesis:

• Sophisticated admin panels — a spreadsheet or direct database access is perfectly fine for the first weeks.
• Multiple roles and permission systems.
• Native apps, if a responsive web app validates the same thing.
• "Nice to have" integrations and advanced personalization.
• Internationalization, dark mode, and anything that starts with "it would be nice if...".

And there are three things you never cut:

1. Analytics and feedback loops. An MVP without measurement is a blind launch: you spent eight weeks and learned nothing. Event instrumentation and a direct channel with users go in during week 2, not week 10.
2. The complete value flow. If a user can't get from start to finish, you're not validating a product — you're showing screens.
3. Basic security and data backups. Minimum viable doesn't mean negligent. Properly stored passwords, HTTPS, and backups are not optional.

What are the classic MVP mistakes?

• Building for scale before validating. Microservices, Kubernetes, and architecture for a million users... on a product that doesn't have ten yet. Scalability should be built when there's traction to justify it. And when the time comes, it can be done: we built the platform for a LAN Airlines campaign that registered 191,219 users with 2,580 connected simultaneously — but that was with proven demand, not before it.
• A six-month roadmap with nothing demonstrable. If the plan doesn't include clickable software before week 4, it's not an MVP — it's a traditional project in disguise.
• Confusing minimum with cheap. The cut is in scope, not quality. The little that exists has to work well, because it's the only thing users will judge.
• Ignoring the signal. Launching and not looking at the data — or looking and not changing the plan — turns iteration into theater.

How much does an MVP cost?

As a reference, a well-scoped MVP costs between US$10,000 and US$30,000, depending on the complexity of the core flow and the integrations required. Simpler projects — an automation, a website with a back office — can start lower, and complex platforms go beyond that range. More important than the number is how you pay: verifiable delivery milestones, working software before each payment, and never the full amount upfront. There's more detail on pricing and engagement models in our FAQ.

When should you NOT build an MVP?

Being honest about this is part of the method:

• When a mature SaaS already solves 90% of your need. Configure it, use it, and validate your business with it. Building your own software is justified when the process is your competitive edge — we cover this in depth in custom software development.
• When the domain doesn't allow "minimum". Regulated processes, healthcare, or flows where a mistake puts other people's money at risk: there, the minimum viable is bigger, and it needs to be scoped that way from the start.
• When nobody will watch the signal. If no one is going to analyze the data or talk to users, the MVP loses its purpose.
• When your problem is an existing system, not a new product. If what hurts is an aging platform nobody wants to touch, that's a different path: legacy system modernization.

If you have an idea and want an honest assessment — including "an MVP is not what you need" if that's the case — contact us: we reply within one business day.

Frequently asked questions

Can you launch an MVP in less than 6 weeks?

Sometimes, if the scope is genuinely small: an automation, a landing page with a payment flow, an internal pilot. But below a certain threshold you're no longer validating a product — you're validating a mockup. For software with real users, measurement, and a complete flow, 6 weeks is the realistic floor.

What happens if the MVP "fails"?

An MVP that invalidates the hypothesis didn't fail: it saved you the cost of spending 12 months building something nobody wanted. That is exactly its job. The real failure is spending the budget without learning anything — and that happens when measurement gets cut, not when the hypothesis turns out to be false.

What tech stack should you use for an MVP?

Whichever your team knows well and lets you iterate fast. We work with TypeScript, Vue/Nuxt, React, Laravel, and PostgreSQL: proven, boring technologies in the best sense. The innovation should be in the product, not in the infrastructure.