8 steps to building an MVP that scales
If you’re planning to build and launch a product, you’re probably familiar with the way it typically goes: Build an MVP, use it to gather feedback, and then completely rebuild V2 later on.
But building an MVP that’s set up to scale as you grow is much smarter in the long run:
- Building something you’re going to scrap is a waste of time and money.
- Having a fully functioning product when you approach potential investors or partners can give you an edge in those conversations.
- After you launch, you’ll need to keep testing and iterating, so you’ll need a product that can scale eventually.
It’s well worth the effort to build something that you can keep adding to and changing as you go. My cofounder, Josh Haas, and I not only did this when we launched Bubble — which made it possible for us to bootstrap our way to thousands of users and more than $1 million in ARR by ourselves, in the five years before we built out the team — we also created Bubble to solve this exact problem.
Here are some steps I’d recommend to build an MVP that scales.
1. Don’t skimp on the user research
Before you start the development process, take as much time as you can afford to do some robust user research.
This will help you identify all the different potential users you might see using your product, plus their needs. It will also give you insights into how those users will interact with not only your MVP, but also the full-fledged product you envision for the future. And the clearer that vision is, the easier it will be to make sure what you’re building today is technically set up to evolve in that direction.
That said, when you’re just starting out, I don’t think it’s always necessary to invest in tooling. Often, it’s better to have a few in-depth interviews with users than a ton of feedback collected with fancy tools.
2. Pick a single user (for now) and then build what’s minimal for them
Once you’ve identified the different personas likely to use your product, my advice is to pick just one. This is easier said than done, but it will help you focus — and build an MVP that’s got only what they need and nothing they don’t.
Often, people build what their users don’t need (or never asked for), so instead of scaling up, you end up scaling down multiple times.
3. Name your short-term goals
And by short-term, I mean for the next couple of years. Do you want to monetize quickly (perhaps to bootstrap)? Prioritize growth (perhaps to sell the company or raise venture capital)?
Your goals will influence which features and design elements you’ll want to include now — and next. Again, this lets you make sure you’re building with the next iteration top of mind.
4. Put a lot of thought into how you build your database
When sketching out your database for the first time, think hard about the relationships you need now and expect to need in the future. This is one of the most challenging parts of a product to go back and fix retroactively, so the more time you spend here, the better off you’ll be.
I like to do this on paper by thinking through examples. For instance, don’t start by asking yourself, “Which fields do I need for a short-term rental marketplace?” Instead, think, “Sam is posting his place on the marketplace — here’s how he’ll describe place, the location, price, its condition, add photos, and so on.”
5. Create a written product roadmap, even if you’re the only one using it
Product roadmaps can feel a little superfluous when you’re the only one building your product, kind of like outlining an essay in college before you start writing. Well, I hate to say it, but your professors were right.
By now, you’ve probably picked up on a common theme of all this advice — anticipating what’s to come, early and often, is the only way to build an MVP that scales easily.
Documenting your product roadmap gets that information out of your mind and onto paper (or a Google Doc), which makes it much easier to keep all the future steps in mind whenever you have to adjust in the face of an unknown unknown.
It can help to start with a roadmap template — there are many to be found online. Explore several and choose the one that works best for you, then start filling it in. Make yourself a list of all the features you can think of, then decide what’s necessary (do those first), what’s pretty important but not critical (make those fast follows), and what’s simply nice to have or unnecessary (save these for later or toss them completely).
6. Build on a platform that scales with you
Often, people start with a design platform for wireframes (like Figma), then a CMS for their landing page (like Webflow), then either code or a no-code platform for their product. That process gets the job done, I guess, but there’s a lot of rebuilding involved.
But as tech becomes more and more powerful, it's possible for one single tool to be able to take you from wireframe to millions in revenue. In fact, that’s exactly what Bubble is designed to do. You don’t need to know how to code (or learn) to use it — ever — which means you can get that MVP off the ground faster and much less expensively. And it can also be the platform you launch on, the platform you iterate on, and the platform you scale on.
Plus, after you’ve launched, using multiple tools to make changes to your product can take a lot of time. A lot of companies built the old way eventually hire a product manager to organize all those different workstreams. But with one tool, you can be your own PM and builder.
7. Avoid technical debt
Technical debt — the cost of rework that arises when you choose a fast, easy solution now instead of using a better approach that would take longer — can kill your plans to scale your MVP without rebuilding. Bandaids, paper clips, and rubber bands can only hold a product together for so long. Taking a little more time now can save you a lot of time (and money) later on.
8. Document, document, document everything
You may think you’ll remember what your thought process was at every step of your build, but take it from me — you absolutely will not. Document the parts of the process that you know you’re going to want to remember and, eventually, communicate. This not only gives you something to jog your memory down the line; it also allows you to conduct strong retros, spot potential future problems, and eventually hire and train more people in the future.
–
Building an MVP that scales may take a bit more work up front, but it’s worth it — for you, for your product, and for your business — in the long run.
🔥 Roast My Landing Page
The ideas in this article seem to come from the cognitive bias of an engineering mindset. Obviously it depends on if you are in the discover or growth phase, but a very small team shouldn't be tempted to deeply think through anything considering technical debt. Your "Discovery" MVP is an experiment about product/solution fit. You should be focused on these learnings. If you are used to creating these discovery experiments you should be building quickly using concise tooling that you have invested being adept at. You may have the foresight to build-in a little flexibility to run a small cluster of experiments on different axises within the some code base. It is all about these learnings.
I used to give a provocative talk about technical debt. On why I rarely have to pay it down as I write off THAT code. The investment was not for an end product, but for that learning. Design for scaling during "discovery" MVP is just procrastination. This thinking was consider heresy at Agile meet-ups.
A "Scaling" MVP is optimised for a whole other set of learnings, but still be less concerned about technical debt than an established product. That is unless it seriously slows your velocity while servicing the current order of magnitude of the scaling. An order of magnitude (or two) of "units of work" will require quite different technical approaches.
The article reflects an engineering mindset bias and emphasizes the importance of conducting experiments for product/solution fit during the discovery phase. It suggests that small teams should avoid excessive consideration of technical debt and instead focus on learning. The author's provocative viewpoint challenges the norm of designing for scaling in the discovery phase, considering it procrastination. Their perspective on technical debt suggests treating it as a write-off for learning purposes.
ChatGPT summary?
there is no such a thing as MVP that scales, everything you build will be dropped and rebuilt again (you will be very foolish if you don't do that).
there is technically a way to make a scalable MVP, that is when you have a very good understanding of the product you will be building (you already have built very similar products 5-10 times) and you have the money to hire a good dev team.
you give very good advice in 1,3,5 but everything else is just a waste of time as it is not achievable or relevant (except the above mention exception)
In my experience this comment is correct.
So after my MVP I need to pay a dev to build a completely different product again?
not immediately, but the MVP by definition is "Minimum" so you will need changes, and at that point, you will realize why companies pay a lot of money to clever people to design and build systems.
it is very likely that the person that builds your MVP has no dev skill to build software, has no incentive to build you a proper one, or has no experience to design it properly. These three are the usual cases based on my experience giving technical advice to startups in the past 2 years.
Also, the above situation is the best-case scenario, a lot of founders get in trouble as soon as they go live with the product they are building as the ting is usually working only in the "bench testing" environment and falls apart as soon as more than 10 people use it as "we are hosting it in the cloud/AWS/Azure" is not the correct response to the question "is it scalable" or "is it secure"
@estraschnov I would imagine that you need a certain level of validation before building an MVP that scales, right? Like if I'm just doing a quick MVP to see what happens, I probably wouldn't make it scalable. But if I've done a lot of market research, etc., then it might be worth my while. Interested in your thoughts on where that threshold is.
I humbly disagree. And I think this is dangerous advice!
Having built many products, some with scale in mind from day 1 and many with a 'proper' MVP mindset. It's clear which approach is better. You're literally not building an MVP if it's built to scale.
You can't validate an idea with just user research. You need to build and launch something.
With that fundamental point, you acknowledge that a lot of what you build early on is totally unproven and WILL change. So why would you build it to scale from day 1 when you have very little evidence there is a need for your product.
How do you even know what your database model 'will' look like? How can you avoid technical debt if you don't know what your product architecture will even look like in 3 months?
This feels like one of those thought pieces where you're re-writing your own history. It may have worked with Bubble, but this is such dangerous general advice to early stage founders and builders.
Paul Graham literally argues the exact opposite, and I'm confident the majority of early stage builders/founders would agree looking back.
Absolutely. Starting small and testing your idea with a simple version first is usually the way to go. This article suggesting building to scale from the start might not fit everyone. Jumping into the deep end with a fully scaled product can be risky before you know if folks even like what you're offering. It's like cooking a big meal before checking if people enjoy the taste.
Building a scalable MVP is like an aspiring musician outlining a stadium tour before releasing their first album.
The only thing that matters is building something valuable. To build something valuable you want to optimize for swings at the plate. Spending time on scalability is time not spend on building something valuable.
This isn't to say that making something scalable that isn't won't be a painful, expensive process but I would much rather go through that process than have a scalable MVP that no one uses.
There are countless examples of successful products that didn't scale, Twitter and the fail whale being one of the more prominent ones.
Here is pretty much the plan I create my MVPs outside of just building the product:
LOVE point #2
I have been working on building a platform for creators - is it important for me to connect with creators before even starting the development to make sure that when the platform is built, there are creators to onboard to it?
How did you decide on which single user or persona to focus on when building the MVP?
How and where can you gather feedback? I never even get enough traffic or feedback to get an idea about the viability of a product
To build an MVP that scales, follow these key steps:
Define a clear vision.
Identify essential features.
Use agile development methodology.
Test rigorously and gather user feedback.
Design for scalability.
Optimize performance.
Plan for growth.
Iterate and improve.
I've had a design agency say to me recently that the start-up could be worth more if built using code and owned by the company, with some no-code tools causing greay areas. Any thoughts on this?
Thanks for this article!
It resonates strongly with my own belief in avoiding short-term fixes. Especially when building an MVP. It is quite easy to forget about the long-run.
Kudos for the sensible approach to MVP development and thoughtful tips on managing technical debt. I share this piece with my dev team!
Good one!
You shouldn't want an MVP that scales . MVPs are meant to get a quick overview of market sentiment , they will never be the final product
I know validating idea, setting database right is very important for every product
But Have never taken setting Roadmap for a product idea into consideration.
I think is will help founders structure their products better.
Thanks for sharing 😊
It took me 2 weeks to build an MVP and 2 months to make it scalable. That would be two months of not showing my MVP to the customers and not gathering the initial list of features that they need if I listened to this advice.
You say that discarding your MVP is a waste of time. But scaling something only to find that you scaled the wrong set of features (because your #2,3, etc customers might want something different) is a much bigger waste.
Build a non-scalable MVP, adjust it according to the feedback of your initial customers, then scale it. They say "Do the things that don't scale" for a reason.
An MVP doesn't necessarily have to be scalable. In my experience, a simpler, more disposable solution is more worthwhile. Anyway, good article.
Shane Braddick here, thanks for the advice!
Thanks @estraschnov and great to see you here.
I have some experience with MVPs, building currently on Bubble. Realizing, how much will change based on the feedback of the first users, the only thing that makes sense is building an MVP on a no-code, easy-to-use and easy-to-scale platform.
Additionally, cannot emphasise how important your 2nd point is — what all these Gen AI startups, popping up everywhere around, are doing is the opposite of that, solving nothing for nobody, instead of focusing on solving one problem and delivering value to one well-defined user group.
Someone said that now, for startups, the question of how to attract users is the most crucial.
2023's marketing costs are no joke, especially on platforms like Google Ads and Facebook. It's tough for startups to be competitive without clients. But fear not! There's a solution: Product-Led Growth (PLG).
Here's the deal: Instead of waiting for clients to come to you, focus on building a killer product that attracts users on its own. You want to create an experience that leaves people saying, "Wow, this is amazing!" One strategy that works like magic is the freemium model. Offer a basic version of your product for free and charge for extra features. Let's say you're running a startup called DataDash, offering data analytics tools. Give users a taste of your limited free version, and when they're hooked, they'll be itching to upgrade for the full range of advanced features.
And also have strong examples of this strategy: Figma, chatgpt, etc. Seems like we should try to build viral, lovable products at first.
This final paragraph is the answer to every SaaS product killer marketing campaign when you have less to spend on marketing.
The product must be lovable to go viral, then pin audiences down with sweet offer.
Love is, and am gonna journalise it, any product that does not meet this last paragraph, am not gonna build.
Thanks for sharing
I would like to express my sincere appreciation to the author of the article "8 Steps to Building an MVP that Scales." This well-crafted piece has been incredibly beneficial to me, providing clear and concise guidance on the essential steps involved in developing a scalable Minimum Viable Product. The author's expertise and ability to present the information in a practical manner have greatly assisted me in my own entrepreneurial journey. Thank you for sharing such valuable insights!
MVP and scale are 2 words that don't come together in my opinion. I agree with most of what you wrote except the number 7 and the idea that the MVP should/could scale. It's okay to have technical debt, you always have some.
The goal of the MVP is to learn as fast as possible what works or not. Having in mind that it should scale is already slowing you down and losing the focus on what matters the most: finding what people really need.
Can I dm you? I think I got an interesting idea for an AI powered SaaS after a deep market research. My Discord id: Vector#4461
i am locking for a devolpor for my games. I am working of summertime sag mod apk and its free. I want to improve my gaming site.
Hello, can you please let me know how to add links to this post? I am trying for a lot of days and no solution.
Its all about how we plan when we grow, scale should be in mind from the beginning. All the best.
What is that sweet spot b/w scrappy and perfect to launch an MVP
I'm happy this approach worked out for you with Bubble.
Spending some time doing initial user research is definitely worth it. Even a few days (cough, dev).
Thanks for the tips! Loving it!
I especially agree with you on document everything - it's so easy to forget but its so important!
What. a post! Thanks al ot.
Good stuff, thanks! I've always been ok with technical debt in my MVPs, and I don't document them much. But other than that, I wholeheartedly agree. I'll have to think on how much time I'm saving (or ultimately wasting) with my approach. Something to noodle on :)