The timeline is mostly a consequence of scope, and scope is a decision rather than a fact. So the more useful question is what you are willing to leave out—and that is a question you can answer this week.
8 min read Walker Thomason
People asking this question usually want a number, and there is a reason nobody credible gives one straight away. An MVP is not a fixed quantity of work. It is whatever you decide the first release is, and that decision moves the timeline more than the technology, the team size or the methodology ever will.
So rather than guess, here is what actually determines the answer, which parts genuinely take time, and what you can do this week to shorten it.
Two products described identically in a sentence can be months apart. "A platform where customers book appointments and we manage them" could mean:
Nobody briefing the second one thinks they are asking for something big. Each item is individually reasonable. Together they are most of a year, and almost all of them are built on assumptions about what customers want, because no customer has used any of it yet.
The question is not "how long will the MVP take?" but "what is the smallest thing that would teach us whether this works?"
Every MVP we have built or advised on has broadly the same phases, though their relative weight varies enormously depending on how well understood the product is at the start.
Understanding the users, the job they repeat, the commercial model and the constraints. If the process being replaced is well documented and the people who own it agree with each other, this is quick. If it exists only in a few heads and they disagree, this is the project for a while—and skipping it does not save time, it moves the argument into the build where changes cost more.
Deciding what makes release one, what is deliberately deferred, and writing down why. This is the highest-leverage time in the whole project and it is frequently rushed. An afternoon spent removing three features saves weeks.
Designing and prototyping the core journeys so they can be clicked through and tested before anything is engineered. It feels like a delay to people impatient to see code. It is the opposite: changing a prototype costs hours, changing a built feature costs days, and changing a built feature that other features now depend on costs a week.
The engineering itself, including the foundations—tenancy, accounts, roles, billing—plus QA and deployment. The visible workflows are usually less than half of this. The rest is the plumbing that makes a product a product rather than a demo.
Getting it in front of real customers, watching closely, and fixing what the first fortnight reveals. Always allow for this. Products do not go quiet after launch; that is when they finally start telling you things.
Worth knowing before you try them, because all four are popular.
Adding developers. Beyond a small team, more people means more coordination, and on a product still being defined it often slows things down. A first release is usually constrained by decisions, not hands.
Skipping discovery. This does not remove the work; it relocates it into the build, where a wrong assumption costs a rewrite rather than a conversation.
Skipping prototyping. Same logic, sharper. Engineering a screen nobody has tried is the most expensive way to find out it was wrong.
Skipping QA. Time saved before launch, spent with interest afterwards, at the worst possible moment—while real customers are watching and your team is trying to learn from them rather than firefight.
All of these are scope decisions, which is the point.
One thing not to cut: the decisions that are expensive to reverse—how customer data is separated, how permissions work, how billing maps to your pricing model. Those are structural rather than features. A narrow first release is good; a first release with no foundations is a rebuild with extra steps.
We built Resova because a client needed something that did not exist. Breakout was opening an escape room venue and needed online booking; nothing on the market fitted how attractions operate. The ambition was a booking platform for an entire industry. The MVP was a platform for one venue.
Release one did two things properly: a fast, mobile-first guest checkout, and a back office where staff could manage bookings, schedules and payments without training. No multi-venue reporting, no marketing automation, no integrations beyond payments. We ran discovery with both audiences—guests and operators—and prototyped both journeys before engineering either. We did settle tenancy, permissions and payment handling properly, even at that size, because those are the things that force rewrites.
It launched alongside the venue's opening and processed hundreds of bookings within weeks. What those early venues asked for reshaped the roadmap considerably—better than our original plan had. Resova went on to serve over 1,000 venues in more than 20 countries and process billions of dollars in payments before being acquired by ClubSpeed, and none of the foundations from that first release had to be torn out.
Had we built the version we could all describe at the start, we would have spent a year building features for an industry we did not yet understand, and launched something worse.
For a genuinely tight first release—one journey, simple permissions, one payment integration, manual admin—months rather than a year, and the discovery and definition work at the front is a small share of that. For a product with several user types, reporting and multiple integrations before launch, considerably longer, and worth asking whether all of it truly has to precede your first customer.
We give estimates after discovery and MVP definition, once the scope, the journeys and the technical approach are agreed. Committing to a date before that is guessing, and the guess is always optimistic. What we can promise earlier is honesty about what a given date would require you to leave out—which, in our experience, is a more useful conversation than a number.
If you want to see how we handle that scoping work, it is set out in SaaS MVP development. If cost is the more pressing question, we have written about what drives the cost of a SaaS build as well.
Bring us the idea and whatever you have so far. The first conversation is about what release one has to prove—which is also the conversation that decides your timeline.