-
Written by:
Asad Abdullah Zafar
- Published
- 8 min read
- Development
Quick answer: To scope a SaaS MVP that ships in 12 weeks, set the launch date first, then choose one type of user, one problem and one job the product must do. Write all of it on one page, including what you will not build. When the work runs late, cut features and keep the date. I treat 12 weeks as the most an MVP should take, so ship earlier if you can.
Here is my opinion, and it may not be what you came for: 12 weeks is too long for most MVPs. If yours needs all 12 just to get in front of a first customer, it is probably too big. Asking how to fit your product into 12 weeks is, I think, the wrong question. The better one is what you can remove until it fits in less.
I am not alone in that. In his Y Combinator talk on planning an MVP, Michael Seibel says most startups should build in "weeks, not months", and his one-line summary is to "launch something bad, quickly". So take 12 weeks as a limit that protects you, not a target to fill.
Fix the date first, then cut to fit
Most projects do this backwards. They list the features, estimate them, and get a date, and then the date slips. The team behind Basecamp flips that in Shape Up, its book on building products, with an idea it calls fixed time, variable scope. In its words, "appetites start with a number and end with a design."
Seibel says something similar. Time box your spec: if you want to launch in three weeks, only what you can build in three weeks goes on the list. That rule removes most arguments before they begin, because the question stops being whether a feature is good. Plenty of good features will not fit.
Write the scope on one page
Seibel makes the point that if you never write the plan down, you can change it without noticing, and a short plan quietly becomes a long one. I would use one page, with these seven lines:
- Launch date. A real calendar date, no later than 12 weeks away.
- The one user. Specific enough to name ten of them. "Small businesses" is too broad. "Bookkeepers who handle ten or more clients" is about right.
- The one problem. What hurts, how often, and what they do about it today.
- The one job. The single thing that user must be able to finish in your product.
- What must exist. Only the screens and steps needed for that job, listed in order.
- What you will not build. This list matters most, so write it out in full.
- How you will know it worked. For example, whether those first users come back and do the job again without being asked.
Get the problem from real users before you write this. Seibel's advice is that users should give you problems and you decide the features. When someone asks for a feature, ask what they are trying to do and how often it comes up.
What I would leave out of the first version
Airbnb's early product had no payments and no map view, according to Seibel. Guests paid hosts in person. Stripe's founders would go to a customer's office and install it for them. If they could launch without those things, you can probably launch without most of this list:
| Feature founders usually want | What to do in the first version instead |
|---|---|
| Self-serve subscription billing | Send an invoice by hand to your first customers |
| Teams, roles and permissions | One account type, and you change anything else manually |
| Admin panel | Edit the database yourself, carefully, or use the simplest tool your framework offers |
| Analytics dashboard | A simple report or a spreadsheet export, or send the numbers by email |
| Single sign-on and social login | Email and password only |
| Mobile apps | A web app that works properly on a phone |
| Integrations | The one your first users can't work without, and no others |
| Onboarding flows | Set up each new customer yourself on a call. You will learn more that way |
Doing things by hand feels embarrassing, but with ten customers it is cheap. You can automate it once you know it is worth doing. Two things I would not cut: backups and basic security. Taking a customer's data and then losing it is not a scrappy MVP. It is just a bad way to lose your first customers.
How I would split the 12 weeks
This split is my own suggestion, not a standard. It assumes a small team and a normal web product, and I would rather you beat it than match it.
| Weeks | What happens | Finished when |
|---|---|---|
| 1 to 2 | User conversations, the one-page scope, data model, simple screen sketches | The page is signed off and the "will not build" list is agreed |
| 3 to 8 | Build the one job, from start to finish, as early as you can | One user could complete the job, even if it looks rough |
| 9 to 10 | First real users try it, and you fix what stops them | Real users have finished the job without you helping |
| 11 to 12 | Spare time for overruns, final fixes, launch to your first customers | Customers are using it |
Notice that real users arrive at week 9 at the latest, and you can bring them in sooner. Also, if you are still choosing a stack during week 3, you have a problem. Decide early, and my Laravel vs Node.js vs Django comparison can help.
When the scope starts growing
It will grow. You will talk to a user or an investor who has an idea, and it will sound important. These are the rules I would keep to:
- Anything new goes on a later list. It only joins this version if something of the same size comes out.
- Check at the halfway point. Seibel expects you to find out early in a sprint that you have planned too much. Cut what clearly isn't important. If nothing qualifies, start cutting important things.
- Do not move the date to fit a feature. I think moving it once makes it easy to move again.
- Do not polish. As Seibel puts it, treating your MVP as special makes you keep changing it instead of launching.
Where I could be wrong
- Some products cannot be this small. Seibel makes the same exception for what he calls heavy MVPs, such as regulated areas like banking and insurance, and hard technology. If yours is one, your first step may be a simple website that explains what you do, and that alone can start the conversations.
- Selling to big companies is different. A rough product may not pass a large buyer's security review. You may need more before anyone can legally use it, though I would still keep the feature list short.
- Airbnb and Stripe are hindsight. They are famous successes, and they don't prove that rough launches work. They only show that rough launches did not stop those companies.
- This depends on the team. My split assumes people who have built similar things before. A first-time team should cut even more, not take longer.
How Loop2Tech helps
Our paid discovery, US$300, is this exercise done with you: process mapping, a written scope, a data model and a fixed quote, and the fee is credited to the build. Web applications start from US$2,000, delivered against the agreed scope, and you own the code, data and hosting accounts. See our pricing page and custom web solutions. If you aren't sure that you need custom software at all, start with custom software vs off-the-shelf. Or send us your idea, and we will tell you what we would cut.
Frequently asked questions
How long should it take to build a SaaS MVP?
In my opinion, 12 weeks at most, and less if you can manage it. Y Combinator's Michael Seibel says most startups should build in weeks, not months. Regulated products and hard technology can take longer, but they can often start with something simple that explains what they do.
What should be included in an MVP?
Only what one type of user needs to finish one job: the screens for that job, a basic login, backups and basic security. Most other things, including self-serve billing, team permissions, dashboards and mobile apps, can wait until real users ask for them.
How do you stop MVP scope creep?
Write the scope on one page, including what you will not build. Set a fixed launch date. Anything new goes on a later list unless something of the same size comes out. If the work runs late, cut features and keep the date.
Should an MVP have payments?
You should try to charge early, but you may not need automated billing. Send invoices by hand to your first customers. Airbnb's early product had no payments at all, according to Y Combinator's Michael Seibel, though you can add a simple payment later if your customers expect it.
What is the difference between an MVP and a prototype?
A prototype shows how something might work, and it is often not usable for real work. An MVP is the simplest version that real users can actually use to solve their problem. You learn far more from the second, because you can see whether people come back.
