Scalability should be considered when developing a Minimum Viable Product (MVP), argues Erik Duindam. An MVP needs to be technically scalable and you need to have a plan on how to scale quickly when your MVP attracts many users and becomes successful. Knowing your possible performance bottlenecks and using common sense while developing your MVP will get you very far, says Duindam.
Erik Duindam, CTO at Unboxd, spoke about scaling teams and technology at the Agile and Software Architecture Symposium 2016 (ASAS). InfoQ is covering this event with Q&As, summaries, and articles.
In the Medium article How I built an app with 500,000 users in five days on a $100 server, Duindam argues that scalability matters when you are developing an MVP:
There seems to be a general consensus in the world of startups that you should build an MVP (minimum viable product) without caring too much about technical scalability. (...) You shouldn’t waste time and money on making a technically scalable product. All you worry about is testing your assumptions, validating the market and gaining traction. Scalability is a concern for later. Unfortunately, this somewhat blind belief has led to some terrible failures.
Duindam provides suggestions for picking a programming language for developing a scalable MVP:
Choosing a lean and fast language is important for scalability, unless you have a lot of money for servers. Choosing a language with a lot of useful available libraries is even more important, since you want to build your MVP quickly. NodeJS, Scala and Go are good languages that cover both of these requirements. They provide a lot of good tools with a lot of good performance.
An MVP has to be developed in such a way that it can handle the load, argued Duindam in his talk at ASAS. You have to think about what is going to happen if you have a million users of your MVP and check if it will be able to handle that. Try to understand where your bottlenecks are and apply common sense tech to write good code and prevent technical issues.
Duindam gave an example of how adding Mongoose’s lean() function when fetching data removed 90% of the server load. If you code isn’t good then you can keep on adding servers, which is not a feasible solution, said Duindam.
InfoQ interviewed Erik Duindam about why a minimum viable product has to be technically scalable and how to design and build a scalable MVP, and asked him for advice on tools for developing scalable MVPs.
InfoQ: Why does a Minimum Viable Product (MVP) have to be technically scalable?
Erik Duindam: The purpose of an MVP is to gather validated learning from a minimal amount of effort. Practically this means that you shouldn’t spend any time on developing functionalities or technology that will not contribute directly to the learning process. Therefore, spending time on beautiful code, architecture and scalability generally makes no sense. Believing that your product is going to take off like a SpaceX rocket – and therefore requires a lot of scalability tech built-in – is just as valid as believing that each SpaceX rocket will actually take off. In an ideal scenario it would, but in reality it probably won’t (ask Zuck). But what if you could make it a little bit scalable without spending more time? And what if your rocket does take off?
Many examples about lean startups and MVPs point out a scenario where you create a landing page to try to sell things to consumers, without actually selling it. You don’t actually build a system with fulfillment, payment and shipment, but only gather people’s email addresses to validate the business and market. This example is easy to understand, but doesn’t work for many MVPs. Sometimes you actually have to test a first version of your tech or product. Sometimes you actually have to get users to try a working product. In those scenarios, you need to have a plan on how to scale very quickly. You should at least consider the possibility that the MVP version of your product might be used in a production scenario. You should consider the possibility that you might get a bunch of users from media coverage or other expected or unexpected traction. You should consider success.
InfoQ: What can you do to design and build a scalable MVP?
Duindam: The most important thing is to make sure that your developers understand what "success" means for your MVP. You and your developers have to understand beforehand what possible performance bottlenecks could be and how these should be handled in case of rapid growth. So the first thing I would do is set up a little plan.
Secondly, a lot of the hardest scalability issues come from laziness and poor design. A great example is the way many developers fetch data from their databases. Many developers love to use some form of database abstraction in their code and then stick by it entirely. For instance, they’d rather perform database queries in a loop than actually writing one fast JOIN query, because the code will allegedly look cleaner, or more object-oriented or simply because it’s "the Rails way". My experience is that this is largely based on insecurity on the developer’s end- not knowing it’s totally fine to use the database abstraction tools differently. So just the realization of the performance impact of your way of programming could already save you most of the headache. Using common sense while developing will get you very far.
InfoQ: Which tools would you advise for developing scalable MVPs?
Duindam: Personally I’m not a huge fan of pushing specific technology or tools, because many packages solve similar problems in slightly different ways. You should do your own research on the best tools for your programming language, database, use case and so forth. It’s not hard to find some performance testing tools that match your language or use case. But let me say some more generic things about this.
It’s important to understand that you can scale any programming language, framework and database system to a reasonable amount of users. There are only a few Dutch tech companies that might actually require very specific programming languages or database systems in order to scale. The rest is simply not big enough to really become a problem. A website like Telegraaf.nl or NU.nl could be built on any technology with a reversed proxy like Varnish in front of it. A website like bol.com could have microservices in play to separate the storefront from backend processes. These can all be done on any language or platform. So the choice of languages, tools and libraries should be based on your ability to find programmers and open source code for them, not on scalability.
