How Long Does It Take to Build an MVP?
By CodexierPublished 6 min read
The honest answer is 'weeks, if the scope holds, and months if it does not'. The build itself is rarely the slow part of an MVP; the slow parts are the decisions before it and the changes during it. This guide gives a realistic week-by-week shape, what each phase needs from the founder, and the decisions that stretch a project past its date.
Discovery and scope
Discovery is where the timeline is really decided. Its job is to turn an idea into one core flow: the single path a user takes from arriving to getting the value. Everything not on that path is written down for later. The output is a short scope document, a list of integrations (BankID, Stripe, Fortnox, an email provider), and a decision on what 'done' means for launch. A founder who arrives with those three already drafted saves a week.
Design and prototype
Before code, a clickable prototype of the core flow. It costs days, not weeks, and it is the cheapest place to discover that the onboarding has one step too many or that the dashboard answers the wrong question. Show it to five people who resemble your users. Changing a screen in Figma takes an hour; changing it after it is built and wired to a database takes a day.
- Wireframes of every screen on the core flow, in order
- One clickable prototype covering sign-up to first value
- Written notes from five short test sessions
- The design system kept minimal: one font, one component set, no custom illustration yet
Build in short cycles
The build runs in one- or two-week cycles, each ending with something you can click. That rhythm is not a methodology preference; it is the mechanism that keeps the timeline honest. A weekly demo surfaces misunderstandings after five days instead of after five weeks, and it gives the founder a natural place to ask questions without interrupting the work every afternoon.
| Cycle | What is usually built | What you need to do |
|---|---|---|
| 1 | Project skeleton, authentication, database, deployment pipeline | Confirm the login method (email, BankID, Google) and the domain |
| 2 | The core flow's data model and first screens | Provide real sample data, not lorem ipsum |
| 3 | The core flow end to end, rough edges included | Click through it yourself; note what confuses you |
| 4 | Payments or the key integration, admin view | Set up the Stripe or Fortnox account in your company's name |
| 5 | Email flows, error handling, edge cases from your testing | Test with two or three friendly users |
| 6 | Polish, performance, security checklist, launch prep | Write the terms and privacy notice, or approve ours |
Six cycles is a typical mid-sized MVP. A single-flow tool can be four; a two-sided marketplace is rarely under eight.
Testing and launch
The last phase is shorter than founders fear and more important than they expect. It covers a security pass (access control, input validation, secrets out of the code), a performance check on realistic data, a GDPR check on what is stored and why, and a launch on the real domain with monitoring and backups switched on. Then the first real users, in a small group, while someone watches the error logs.
Soft launch
Ten to fifty invited users for two weeks. Enough to find the problems, few enough to apologise personally.
Public launch
Only after the soft-launch fixes. The launch day itself is a marketing event, not an engineering one.
First month after
Budget for it. The first real users generate the most valuable change list you will ever get, and someone has to act on it.
What stretches the timeline
The build almost never slips because typing was slow. It slips for five reasons, and all five are decisions. Scope added mid-build ('while we are at it') restarts the design of screens already finished. Integrations with third parties whose documentation is thin or whose sandbox behaves differently from production. Decisions that wait for a weekly meeting instead of a same-day answer. Content and assets (copy, terms, logo, product data) that arrive late. And perfectionism on screens nobody has used yet.
When you should not start the build yet: if you cannot name the one core flow, if you have not spoken to prospective users, or if the budget only covers the build and nothing for the month after. In those cases the planning blueprint on its own, or simply more customer conversations, is the better spend. If the scope is ready, the pricing page has the fixed prices and delivery windows, and a short call will tell you honestly which of the four phases your project is actually in.
- MVP Development & DeploymentFixed-price build of a scoped MVP in short cycles, deployed on your domain with monitoring and a handover.
- MVP Planning & Architecture BlueprintThe discovery phase on its own: scope, core flow, integrations and a build plan you can take anywhere.
- Book a free 15-minute callDescribe the idea and what exists today; we say which phase you are in and how many weeks the rest should take.
Frequently asked questions
Can an MVP be built in two weeks?
A prototype can, and a very narrow tool with no payments or integrations sometimes can. A product with sign-up, a core flow, payment and an admin view is not a two-week project if it is meant to take real customers. Beware of quotes that promise it; the time usually reappears as bugs after launch.
What can I do as a founder to keep the timeline?
Answer questions the same day, provide real content and sample data early, set up third-party accounts (Stripe, domain, email) in your own name before the build starts, and refuse your own 'while we are at it' ideas until after launch. Founder response time is the single largest factor we see.
Does no-code make it faster?
For a simple flow, yes, and it is worth considering. For anything with custom logic, BankID, or data you will want to own and migrate later, the time saved up front is often spent later working around the platform. The right question is not speed alone but what happens in month six.
How long does it take to build a two-sided marketplace?
Longer than a single-flow product, because there are two user types, two onboarding flows, matching or search, and usually payments split between parties. Eight to twelve cycles is a realistic range for a first version. Many marketplace founders launch one side manually first, which shortens the build considerably.
Want a realistic timeline for your idea?
Fifteen minutes: you describe the product and what exists today, we tell you which phase you are in, how many weeks a focused build should take and what would stretch it.
Book a free 15-minute call