Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage Articles Building a Scale-Ready MVP

Building a Scale-Ready MVP

Leia em Português


Key Takeaways

  • After 15 years of Agile and Lean Startup, most companies - start-ups and large companies alike -  launch new initiatives with Minimum Viable Products (MVP) and Build-Measure-Learn loops
  • There are some common traps that organisations fall into when building an MVP
  • Minimum viable is a trade-off, and getting the balance right is hard
  • While the MVP is often planned to be throw-away, there is seldom time or capacity to start from scratch and the MVP becomes the production product
  • There are some useful checks that can be used to walk the fine line between robustness and speed when producing an MVP

In these times of turmoil, many executives are considering information technology as a strategic asset to weather the difficult times ahead. They launch projects to build digital products and seize new opportunities, but even with strong pressure to release as fast as possible, there are important lessons to keep in mind in order to avoid squandering vital opportunities.

After 15 years of Agile and Lean Startup, most companies - startups and large companies alike -  launch these initiatives with Minimum Viable Products (MVP) and Build-Measure-Learn loops, before embarking on large-scale projects. The logic is sound: assemble a small team, develop in small increments to gather solid customer feedback with fewer costs, and validate business and technical hypotheses before committing large resources on an idea.

But what happens after the MVP is out? What then?

Success is an option! The MVP has shown that there is a business opportunity to pursue, and the company knows how to go for it. The logical move at this stage is to turn the knobs to 10 and put more resources to seize the opportunity.

This is when the trouble starts:

  • the CTO starts adding new developers to the team, but the new hires are lost in pieces of code that were hastily put together and are now difficult to understand;
  • the number of bugs keeps increasing until the team realizes that they are not caught before they reach customers because the test coverage is poor;
  • the developers of the initial team now need to train other engineers, but they are too junior or not prepared for this task;
  • as the development team grows, CTOs find themselves unable to create different teams because the codebase structure doesn’t allow for these teams to work separately without disrupting each other;
  • the application is starting to slow down as the number of concurrent users increases, but it turns out that this is due to the poor design of the data model: changing the model of the database would result in major changes in the existing code;
  • the SEO team is requesting major changes in the web pages structure, but the way components were designed requires a major rewrite of the frontend;
  • the infrastructure team would like to add a few server instances to support the increasing workload, but the application does not support it; and so on.

At this point CTOs and their teams typically advocate for a complete rewrite, which is seldom realistic. The product has started to gain momentum, the pressure on both the top line and the bottom line of the company would be too high.

This is a common situation and one we found ourselves again some time ago, working on a large project in the transport industry. The project was ambitious and risky, so the initial team decided to be pragmatic and not over-invest in the first MVP. The MVP quickly out, the idea was validated by excited users and the team hurried to take into account their feedback and release a second version to delight these early-adopters. A few versions later, rushing to keep the momentum going, the team was caught up by early rash decisions, leading to a very difficult period for all involved. This was a wake-up call, prompting us to dig deeper into the issue.

It turns out that "Minimum Viable" is, in fact, a trade-off. On the one hand, anticipating too much change leads to a bloated application and too much up-front design, which is exactly the problem agile was meant to solve in the first place. On the other hand, going the quick & dirty way is a sure recipe for a costly rewrite and months of delay down the road.

Figure 1 - The MVP Tradeoff

Lean offers a proven perspective on this problem: Good Thinking, Good Products. Technical solutions can be discussed at length, but building MVPs that can scale is first and foremost a skill developed project after project by engineers.

Over time, we have evolved a better picture of what makes a scalable MVP. For instance, in a recent project we started building an application for sports enthusiasts. The first version of the app was built for a local tournament, with only a few thousand users. In its third generation, the application now handles millions of users for worldwide events.

The tech lead in charge of the first MVP framed the scaling challenge as a set of six questions.

1. Is the data model robust?

The fastest way to build the data model would have consisted in analyzing the first feature set and designing the data according to what was presented on the screen. But after a few evolutions, this would have led to a bloated model and difficult changes.

Instead, the tech lead spent a few hours getting the domain model right, working with sports professionals to understand how to model tournaments, players, and so on. He then tried to figure out how the model would evolve at scale, with hundreds of matches and millions of users, to get a sense of how to set up the data and prepare the more obvious database optimizations. The whole process didn’t take much more time, but it resulted in a model that was robust enough to not require major changes after a few months. One of the main reasons for this success is that he was working on his modelling skills, inspired by the concepts behind Domain Driven Design.

2. Is the code base always improving?

The first release of the MVP was built on a monolithic back-end, simple to set up and administer and largely sufficient for the expected workload. However, the tech lead was intent on making the code healthy enough to allow for splitting functions among different server instances in the future, when the team structure or performance expectations would require it.

As a rule of thumb, he was asking himself the same question all the time: is the code base improving or degrading? He would often ask developers to carve some time for refactoring, in order to remove obvious duplications or unwanted dependencies. Even though he was not aiming for perfection, he always kept a feeling of the overall state of the code and would not let it degrade below a certain threshold.

Another area of focus for him were the APIs. He knew from past experience that getting the APIs wrong would result in many evolution requests and performance issues, so he also made sure to design a set of interfaces that formed a coherent whole, independently of the specific needs of the first screens.

Getting the code and APIs right enough didn’t take much longer, because it was based on the personal education of the tech lead, who had invested time in mastering design principles and studying various approaches for designing APIs.

3. Is the test coverage always improving?

Another common trade-off when writing MVPs is deciding on the right level of test coverage. Here again, perfection was not his ultimate goal. His approach was guided by three principles:

  • Start right away with a mix of endto-end tests only for the main success scenarios, and cheaper unit tests for the edge cases.
  • Make sure that the test coverage increases every week.
  • Never let failing tests creep in the test suite, fix everything right away.

As a result, the developers who arrived later on the project had more confidence when making changes, and they had examples on how to add their own tests.

4. Is it possible to build and deploy the application with a single command line?

The build chain often gets overlooked in new projects. The tech lead had experienced the pain of dealing with messy configuration files and build scripts on previous projects, so he remained adamant that the application be always deployable from a fresh environment with a single command line. This brought extra attention to the quality of the build chain, and brought developers on his team to realize that they needed to raise their scripting skills.

This paid off later with everybody on the team being able to deploy the application, not just one or two experts. There were also less incidents, since there were less opportunities for people to make a mistake under the stress of a deployment in the production environment.

5. Is the system properly monitored and are rollbacks easy?

Having a clean model, a healthy code base, a solid test suite and an easy build chain are different ways to nurture confidence in developers. A project starts to slow down when the team starts double guessing every change, fearing to break things and disrupt the business. The moment of peak anxiety comes when the system is deployed in production.

The tech lead’s main theory on this topic was reversibility, and involved two components:

  • Being able to rollback changes immediately. This was achieved with a mix of feature flags, smart data model versioning, and when the backend was split in different processes the ability for one component to work with several versions of the other systems.
  • Having a solid monitoring system in place from day one.

Figure 2 – Building developer confidence

6. Is the business question clear?

The importance of these various strategies increases as the application grows. As a consequence, an effective approach to avoid the pitfalls of growth is to build less software. In the case of an MVP, this means keeping the emphasis on the “M” by being crystal clear on what business hypothesis the MVP is supposed to test. In this case, this led to sharpen the expectations of the MVP. It was not only about tracking conversion and retention rates: the deeper questions evolved around specific points of user behavior that the company needed to clarify.

Moving forward

There is no such thing as building a piece of software once and for all: an application is a system which grows over time, as the business around it changes. This has been the focus of the discussion on refactoring since the late 90s, but few developers truly walk the talk.

We need to better understand how systems evolve, and how we can design them to scale upfront. And for this to work, we need engineers that become curious about this topic and make it a core element of their self-development, exploring and sharing ideas with their peers.

Where to start? As a first step, CTOs can take a hard look at their current MVP projects. What are their own criteria for what makes a healthy MVP? And what is the perspective of each tech lead on this topic? And if need be, what can be done to get the projects back on track before it is too late?

Figure 3 - The tech lead’s MVP health check

These are difficult questions, but they are good ones. An MVP in itself is of little use if it does not help companies to reap large-scale benefits in record time. In other words, a good MVP is a scale-ready MVP.

About the Authors

Regis Medina is an executive coach. He was one of the pioneers of agile in the late 90s and has been studying lean for the past ten years,  working with CEOs to build scalable and adaptive companies. He is the author of Learning to Scale.

Michael Ballé is a business writer, researcher, and executive coach. He has been studying lean as a learning system for the past 25 years. He is co-author of The Lean Strategy, The Lean Sensei and The Gold Mine Trilogy.

Benoît Charles-Lavauzelle is a tech entrepreneur. He co-founded in 2009 Theodo Group, a digital consulting firm of 350 people, that helps large corporations and scale-ups become tech leaders in their industries


Fabrice Bernhard is the co-founder and Group CTO of Theodo, a lean software consultancy whose mission is to transform organizations - from start-ups to large companies - to build better digital experiences and become tech leaders in their market. 

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p