Most teams treat scaling as a decision they make once, on a Tuesday, in a meeting with a slide deck. It isn't. Scaling your MVP (Minimum Viable Product) is the stretch of the journey where most product bets are quietly won or lost, and it takes deliberate planning, product refinement, operational efficiency and a monetisation model that survives contact with real customers.
Think of it as a canal rather than a motorway. You do not simply open the throttle: you move through a series of locks, and at each one the water has to reach the right level before the gate ahead of you will open. Push against a closed gate and nothing happens, except that you burn fuel.
The Scale Readiness Gates are six sequential checkpoints between a validated MVP and a scalable product, covering market, team, product, operations, reach and monetisation, and each one has an exit condition you must meet before releasing the next tranche of budget. Six gates, each with a cost of getting it wrong and a signal that tells you the water is level. It is how we frame the question at Imaginary Cloud when a client asks whether an MVP is ready for a scaling budget.
Most new businesses do not survive their first five years. The US Bureau of Labor Statistics Business Employment Dynamics series (Table 7, cohort data through 2025) has shown for two decades that around a fifth of new establishments close within their first year, and roughly half are gone by year five. Software products tend to fail for the same reason most businesses do: they get built at full scale before anyone has confirmed the market wants them.
That is the risk the MVP approach exists to remove. Build the smallest version a real customer can actually use, put it in front of them early, and an expensive assumption becomes a cheap answer.
A minimum viable product is a stripped-down version of your product that tests and validates your business idea with the fewest resources. It carries just enough functionality for a real user to complete a real task, so you learn what people do rather than what they say they would do. Our ultimate guide to the minimum viable product covers the build side in full, and our work with FluxPlan shows the shape of it in practice, where the job was to turn an idea into a fundable product concept with defined requirements and interface mockups.
Why does it matter? Because it lets you validate the idea quickly, gather input from potential customers, and decide from evidence rather than opinion. For an executive sponsor the case is blunter still: an MVP lowers the chance of writing off a full build, cuts the capital at risk before product-market fit (the point at which a defined group of customers keeps using the product without persuasion), and shortens time to first revenue.
Not every MVP is a working product. Choosing the wrong type is the most common way teams spend build budget answering a question they could have settled in a fortnight.
The concierge MVP delivers the outcome by hand. The customer gets the service; your team does manually what software would eventually do. It tells you whether anyone wants the outcome, and it needs no engineering at all.
The Wizard of Oz MVP puts a real interface in front of the user with people working behind it. It looks automated. It isn't. Use it when the interaction, rather than the outcome, is the thing you are unsure about.
The single-feature MVP builds one workflow properly and nothing else. This is what most software MVPs should be, and it is the type most often inflated into three or four workflows by the time it ships.
The landing page or smoke test MVP measures intent before anything exists. It answers whether the proposition is worth building, not whether the product works.
That an MVP is a prototype. A prototype demonstrates; an MVP gets used. If nobody outside the team completes a real task with it, it has tested nothing.
That "minimum" means low quality. Minimum refers to scope, not to standard. One workflow that works reliably teaches you something. Five workflows that break teach you only that people dislike broken software.
That the MVP is version one of the final product. Parts of it are meant to be thrown away, which is exactly why the technical debt question below matters as much as it does.
That validation means positive feedback. An MVP showing nobody will pay has done its job and saved the budget. That is a successful MVP with a negative result, not a failure.
Here is what that looks like in practice. Suppose you want to build a platform matching specialist contractors to short engagements. The full product implies profiles, search, matching, contracts, payments and reviews. The single-feature MVP is the match itself: a form, a manually curated shortlist returned within a day, and payment taken through an invoicing tool you already own. If clients will not accept a shortlist they did not generate themselves, no amount of search UI will rescue the idea, and you have learnt that for the cost of a fortnight rather than two quarters.
The path from MVP to a working business breaks into five stages. Each has its own exit condition, and moving before you meet it is the most reliable way to waste scaling money.
Read these as locks on the canal, not as milestones on a map. The question at each one is never "have we been here long enough?" It is "have we earned the right to spend the next tranche of budget?"
Despite everyone's best efforts, plenty of MVPs never reach their potential. Three causes account for most of it:
Inadequate market fit: the product does not match what the intended audience actually needs, usually because the MVP was validated with people who were friendly rather than representative. This is the single most common way products die. In CB Insights' analysis of startup post-mortems, "no market need" sits at the top of the list, ahead of running out of cash, which is often a downstream symptom of the same problem.
Poor execution: the product works in a demonstration and breaks under real use. Slow pages, broken edge cases and confusing flows all read to a customer as an unfinished product, whatever the roadmap says.
Inadequate resources: the team lacks the capacity or the skills to deliver the vision, and the gap only becomes visible once the scaling work starts.
To dodge these, test your MVP with users who represent the market rather than your contacts list, develop the product on the back of that feedback, and be honest about the skills and budget the next stage demands before you commit to it.
An MVP is a milestone, not the destination. To succeed commercially you have to go past it and build a Minimum Marketable Product (MMP): a product that has reached a marketable standard, with a clear value proposition and a distinct offering.
The move is a shift in what you optimise for. An MVP optimises for learning, so rough edges are fine. An MMP optimises for revenue, so they are not. In practice that means three things:
The reason to name this stage separately is budgetary. MVP spend is research spend, written off if the answer is no. MMP spend is investment against a forecast. Treat the second like the first and you end up scaling something that was never worth scaling, and that muddle is the one we most often find when we are brought into a product that has stalled after a promising launch.
An MVP is built to be discarded, at least in part. It takes shortcuts on purpose: one database doing several jobs, authentication bolted on, no test coverage on paths nobody was sure would survive. Those shortcuts are correct while you are still learning. They become the main brake on growth the moment you are not.
The scale of that drag is easy to underestimate. McKinsey's research on technical debt found that CIOs divert between 10 and 20 percent of their new-product budget to servicing it, and reckon it accounts for as much as 20 to 40 percent of the value of their entire technology estate. Left unpriced, debt quietly taxes every release you ship.
Before scaling, put the codebase through three questions.
What breaks first under load? In the MVP work we take over, it is usually the data layer rather than the application code: the unindexed query and the synchronous third-party call that nobody noticed at pilot volumes, and everybody notices once real traffic arrives. When we re-platformed the FlippedNormals marketplace, the constraint was exactly this. The existing technology had become a brake on growth, so we moved it off WordPress onto a custom platform and then onto AWS for a more scalable footing before adding features, completing the first stage in two months.
What is unsafe to change? Any area with no tests, no documentation and one person who understands it is a part of the product you cannot iterate on. That is the debt that slows every future release, not just this one.
What was built for an assumption that turned out to be false? Validation invalidates as well as confirms. Code written for features nobody adopted should be deleted, not carried forward and maintained.
The rewrite-versus-extend decision falls out of that audit rather than out of taste. Extend when the architecture holds and the debt sits in identifiable modules. Rewrite the component, not the product, when a boundary is wrong at the structural level and every new feature has to work around it.
Deferring the decision rarely produces one dramatic failure. In our experience it shows up as delivery slowing quarter on quarter while headcount rises, and that is a much harder conversation to have with a board than a planned month of remediation would have been.
The six sections that follow are the gates themselves. Each carries a cost for getting it wrong and a signal that tells you it has been passed. Work them in order, and treat any gate whose signal has not appeared as a reason to stop rather than a box already ticked.
To scale an MVP you first have to understand the market and the customers you are scaling into. That means research, analysis and a genuine willingness to hear feedback that contradicts the plan. Forbes' steps to identify your target market is a sound starting point. (Editor's note: confirm or replace this Forbes URL.)
Begin with your audience's demographics, behaviour and needs. This evidence tells you which features to prioritise and, more usefully, which ones to drop.
Then find the pain points and the openings. What problem does your product solve, and where is it weakest right now? That is what shapes the roadmap and keeps you ahead of the competition.
Finally, look outward. What do your competitors do well, and where can you be different in a way a customer would actually notice and pay for?
Cost of getting it wrong: this is the cheapest gate to be wrong at and the most expensive to skip. Every later investment, in team, infrastructure and marketing, compounds whatever error you make here.
Readiness signal: you can name the segment that retains best, and explain why, without guessing.
Scaling changes what the team is for. An MVP team optimises for speed of learning and runs happily on generalists and informal decisions. A scaling team has to sustain a codebase, an infrastructure bill and a support load at the same time, and that changes who you hire and in what order.
The first three hires after an MVP are usually the same, usually in this sequence. Someone who owns the production environment, because uptime turns into a commercial promise the moment you start selling. Someone who owns quality, because the test coverage you skipped during validation is now the only thing between a release and a customer. And a product owner with the authority to say no, because the backlog after launch grows faster than any team can absorb.
Then make decision ownership explicit. Name one person accountable for the release decision, one for the architecture decision, one for the priority decision, and write down who they consult rather than who they must convince. Most delay in a growing product team is not disagreement. It is nobody being sure who decides.
Culture follows structure, not the other way round. If reviewing someone else's code and writing a post-incident note are part of the work and visible in the sprint, collaboration is real. If they are what people do after hours, no statement of values will conjure it into being.
Cost of getting it wrong: hiring ahead of a validated roadmap converts fixed costs into burn, the monthly cash the business consumes beyond what it earns, without adding throughput. Hiring behind it means the roadmap slips at precisely the moment the market is paying attention.
Readiness signal: your team is delivery-constrained rather than direction-constrained. If priorities still change weekly, more people will not help.
With the team in place, turn to the product: user testing, acting on what it shows, and improving rather than settling.
Run user testing to get real-world feedback. It will show you where the product loses people, and that is almost never where the team expects. The Nielsen Norman Group's usability testing guide covers the basics well.
Then make the changes and measure whether they worked. Iteration without measurement is just churn. The work is often narrower than a rebuild: when AppTweak wanted to surface a new insight from their data science team, a focused dashboard refactor did the job.
Keep improving against evidence. Watch for the shifts that change what your customers expect as standard, and treat those as requirements rather than as innovation.
Cost of getting it wrong: a product that scales an unresolved usability problem simply spends more money losing more users.
Readiness signal: task completion rates hold steady as new cohorts arrive rather than dropping with each one.
Operational tooling earns its keep at the point where coordination costs more than the work. Three thresholds tend to mark that point.
The first is team size. Informal coordination holds to roughly eight or ten people. Past that, work in progress stops being visible to everyone and a shared tracker pays for its licence.
The second is support volume. Once inbound requests cannot be answered from one inbox without something slipping through, a helpdesk and a CRM stop being administrative overhead and start protecting revenue.
The third is release frequency. Ship more often than once a fortnight and manual deployment and manual regression testing become the constraint on how fast the product can change. Automating the pipeline pays back inside a quarter.
The same discipline applies to vendors and to shiny technology. Choose suppliers on the response time you can hold them to, not on the warmth of the relationship. Adopt a technology only when you can state the threshold it clears: machine learning is worth the investment when you have enough labelled data for a model to beat a rule you have already written down. Cannot describe the rule? Then you are not ready for the model.
Cost of getting it wrong: manual process stays invisible until volume triples, at which point it surfaces as customer-facing delay rather than as an internal inconvenience.
Readiness signal: the same headcount can serve twice the customers without overtime.
Reach is a sequencing problem, not a channel problem. Add one channel at a time, and only once the previous one has a cost per customer you can predict.
Start with the channel your existing customers already used to find you, which you can learn from a single question at sign-up. Search engine optimisation (SEO), the practice of earning organic visibility in search results, compounds but pays back over quarters rather than weeks. Paid advertising is immediate and stops the day you stop paying. Content sits between the two. Which one you begin with depends on how long your runway is, not on which is most effective in the abstract.
Two thresholds tell you when to add the next channel. A stable customer acquisition cost in the current one, measured over long enough to survive a bad month. And a retention curve, the proportion of a cohort still active after one, three and six months, that flattens instead of falling to zero. Buying traffic into a product people leave is the most reliable way to convert marketing budget into nothing at all.
Referral schemes belong at the end of that sequence, not the start. They work in proportion to how willingly customers already recommend the product, so a referral scheme launched to paper over weak retention just amplifies the wrong signal.
Cost of getting it wrong: paid acquisition against an unproven retention curve buys you customers who leave, and that spend does not come back.
Readiness signal: customer acquisition cost is stable or falling while retention holds.
The last gate: assess your revenue model, implement it well, and keep it under review.
Test the model against both business objectives and customer expectations. Freemium, subscription and advertising-based models each impose different obligations on the product, so choose on fit rather than on fashion.
Then implement the tactics that suit your audience: additional features, a paid tier, or advertising, depending on how your users derive value. For G7FX we built exactly this kind of tiered access, with gated subscription levels handled through Stripe and PayPal.
And keep looking at it. Pricing set at MVP stage was set with the least information you will ever have about willingness to pay.
Cost of getting it wrong: pricing is the fastest lever on margin and the slowest to correct once customers have anchored on a number.
Readiness signal: revenue per customer is growing without a matching rise in churn.
Scaling an MVP takes strategy, product refinement, operational efficiency and effective monetisation, in that order. Worked together, the Scale Readiness Gates let you reach new customers, grow revenue and build a product that outlives its launch.
The six gates, and the signal that each has been passed:
Back to the canal. Every lock has a level the water has to reach before the gate opens, and no amount of pushing changes that. Stay close to the evidence, be willing to hear that a gate has not been passed, and pay down the technical debt before it starts setting the pace of everything else.
A minimum viable product is the smallest usable version of a product, built to test a business assumption with the least possible investment. It carries just enough functionality for a real user to complete a real task, so the team learns from behaviour rather than opinion before committing to a full build.
Stop when the MVP has answered the question it was built to ask. Usually that means retention has stabilised, users complete the core task without support, and the remaining backlog is about quality and scale rather than whether anyone wants the product. Iterating past that point just delays revenue.
An MVP optimises for learning and is allowed to be rough. A Minimum Marketable Product optimises for revenue: clear value proposition, defined USP, and a standard of finish a customer will pay for. MVP spend is research. MMP spend is investment against a forecast.
There is no fixed timeline, because the constraint is evidence rather than effort. Each gate takes as long as its exit condition takes to meet. Teams that set calendar deadlines for gates they have not passed usually end up scaling an unvalidated product.
Rewrite the components where a structural boundary is wrong and every new feature has to work around it. Extend where the architecture holds and the debt sits in identifiable modules. The decision should follow a codebase audit, not a preference for starting clean.
A great deal, deliberately, while you are still learning. Shortcuts on test coverage, infrastructure and abstraction are the right trade for speed at validation stage. They stop being acceptable the moment the product is being scaled rather than tested, which is why the audit belongs before the scaling work rather than after it.
The main types are the concierge MVP, delivered by hand with no software; the Wizard of Oz MVP, which looks automated but has people behind the interface; the single-feature MVP, which builds one workflow properly; and the landing page or smoke test, which measures intent before anything is built. Which one is right depends on the assumption you most need to test.
If you are weighing up whether your MVP is ready to scale, we run a scaling readiness review: a look at the codebase, the architecture and the delivery constraints, with a written recommendation on what to refactor, what to rewrite and what to leave alone. It takes about two weeks. Talk to us about your product.
Alexandra Mendes is a Senior Growth Specialist at Imaginary Cloud with 3+ years of experience writing about software development, AI, and digital transformation. After completing a frontend development course, Alexandra picked up some hands-on coding skills and now works closely with technical teams. Passionate about how new technologies shape business and society, Alexandra enjoys turning complex topics into clear, helpful content for decision-makers.
Inês Silva is a Project Manager with over four years of experience writing about software delivery, agile methodologies, and tech leadership. Because she started her career as a developer, Inês brings a real, deeply technical understanding to the management side of things. She loves bridging the gap between big-picture business strategy and day-to-day engineering execution, and she's passionate about sharing practical tips that help teams collaborate better and ship great products.
People who read this post, also found these interesting:
-%2520Survey%2520Insights.webp)
