From MVP to Scale: Building a Product You Won't Rewrite
An MVP should test your riskiest assumption quickly, but the code that proves the idea should also be the code you grow. Here is how we balance the two.
The trick with an MVP is building the smallest thing that proves your idea, without writing code you have to throw away the moment it works. Founders tend to hear two contradictory pieces of advice: move fast and accept mess, or build it properly from day one. Both are partly right, and both fail when applied without judgement.
Here is how we approach MVP development at Amygdal: cut scope aggressively, but keep the foundations clean, so that success means adding to the product rather than starting again.
Start from the riskiest assumption
An MVP is not a smaller version of the whole product. It is a test of the thing you are least sure about. For one founder that is whether users will pay; for another, whether a technical approach works at all; for a third, whether two sides of a marketplace will both show up.
In discovery we ask founders to rank their assumptions by how fatal they would be if wrong, then design the MVP around the top one or two. Everything that does not help test them goes onto a later list. This is the single most effective way to shorten timelines, and it is a product decision rather than an engineering one.
Where to cut, and where not to
Speed and quality are not opposites if you are clear about which corners are safe to cut. Our rough rule:
- Safe to cut: admin panels (use the database or a simple internal tool), edge-case settings, multiple pricing tiers, polished onboarding, most integrations, internationalisation, and features for user types you have not yet met.
- Not safe to cut: a sensible data model, authentication done properly, typed code, automated deployment, basic tests around money and permissions, and analytics.
The items in the second list are cheap to do at the start and expensive to retrofit. A bad data model in particular will tax every feature you build afterwards. Skipping them does not make an MVP faster in any meaningful sense; it just moves the cost to the worst possible moment.
Choose foundations you can grow on
We build most MVPs on a stack we know will carry the product well beyond validation: TypeScript across the board, Next.js or React Native for the client, NestJS or a lean Node.js service for the API, and PostgreSQL for data. It is not exotic, and that is the point. Hiring is easier, documentation is plentiful and the path to scale is well understood.
We also deploy to managed platforms early. A product that can be deployed in one command from day one keeps the feedback loop short, and it avoids the classic situation where the MVP only runs on a single developer's laptop.
Instrument from day one
An MVP's job is to produce evidence. If you cannot see what users actually do, you have built a demo, not an experiment. Before launch we agree with the founder on the handful of events that matter, such as sign-up, activation, the core action and payment, and wire them into analytics along with error monitoring.
That evidence is what tells you whether to double down, pivot or stop, and it is what investors will ask about. Retrofitting analytics after launch means losing the most informative weeks of data you will ever get.
Scaling the parts that earned it
Once traction is real, scaling should be deliberate. We look at where users actually spend time and where the system strains, then invest there first. In practice that tends to mean:
- Hardening the core flows: error handling, edge cases and performance on real devices and networks.
- Adding infrastructure as it becomes necessary: caching, background queues, search and observability.
- Building the admin and support tooling that was skipped, now that you know what operations really need.
- Expanding the team, with the structure (design system, CI/CD, module boundaries) that lets more people work in parallel.
Because the foundations were sound, each of these steps adds to the MVP rather than replacing it. If you have just raised on the back of your MVP, our follow-up post on scaling an MVP after a seed round goes into that phase in more depth.
Working with an outside team on an MVP
Many founders build their first version with an external software development company, and that can work very well if a few things are agreed up front. The founder should own the repository, cloud accounts and app store accounts from the first day. Demos of working software should happen every week or two, not just at the end. And the team should write down the main architectural decisions as they make them, so a future in-house engineer can understand why things are the way they are.
Equally important is a shared definition of done for the MVP itself: the specific evidence that will count as validation. Without it, MVPs drift into full products, budgets stretch and the original question never gets a clear answer.
Choosing the right platform for the MVP
A common early question is whether to start with web, mobile or both. Our default advice is to start where your riskiest assumption is cheapest to test. For many B2B products that is a web app, which is faster to iterate on and needs no store review. For consumer products built around daily habits, location or the camera, a mobile app may be the only honest test of the idea. Building both from the start roughly doubles the surface you have to maintain while you are still learning what the product is.
Where mobile is needed, React Native lets one team cover iOS and Android, and a shared TypeScript codebase means the web app and API can reuse types and validation. That keeps a small team productive without locking you into a platform choice you might regret.
When a rewrite is actually justified
Sometimes the honest answer is that a prototype should be replaced: it was built in a no-code tool that cannot support the product's needs, or the data model encodes an assumption that turned out to be wrong. Even then, we prefer a staged replacement, moving one area at a time behind the same interface, over a big-bang rewrite that freezes product work for months.
Building your MVP with us
We work with founders from first scoping through launch and scale. If you have an idea to validate or an MVP that needs a stronger foundation, have a look at our custom software development service and get in touch.
