Scaling from prototype to final product

IT companies in Sri Lanka

A few tips from us on how to scale an app as an MVP gains traction

“Premature optimization is the root of all evil.” – Donald Knuth

Building an app and scaling it to millions of users is tough. As any seasoned developer knows, there is a lot that can go wrong, which is why it is always better to follow an iterative approach starting with an MVP (minimum viable product). The logic is sound: assemble a small team, develop in small increments to gather customer feedback with fewer costs and validate business and technical hypotheses before committing large resources to an idea.

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

The reception to the MVP may show that there is a business opportunity to pursue. The logical move at this stage is to put the pedal to the metal and allocate more resources toward the project.

This is when the trouble starts. It is normal for startups to adopt shortcuts in the engineering and architecting process in order to ship an MVP on time while making do with extremely limited budgets. Unbeknownst to them, this approach can often lead to costly setbacks such as those below:

  • New development efforts are hampered as new developers get lost in pieces of code that were hastily put together and are now difficult to understand;
  • The number of bugs keeps increasing and the development team starts spending more time fixing bugs than on developing new features;
  • Resource-intensive processes such as AI modules may have been implemented in sub-optimal ways to reduce development complexity and time, but turn into a headache for developers to fix later on 
  • the app starts to slow down as the number of concurrent users increases, sometimes even crashing under moderate loads

It is at this point that founders, CTOs, and developers advocate for a complete rewrite of the app which is seldom realistic. The product has just started to gain momentum, and the pressure on both the top line and the bottom line of the company would be too high.

In the search for a quick remedy, developers typically consider scaling the app using hardware, which is now quite cheap thanks to large volumes of AWS/Azure credits that are doled out by service providers for free in order to drive sign-ups. Though this approach will make scalability issues go away for some time, it won’t actually solve the problem. In effect, it ‘kicks the can down the road’, thus leading the original problem to snowball into something much bigger and harder to fix.

That is why we at Calcey are strong advocates of Scalable MVPs and techniques. 

Most people fail to understand the thinking behind MVPs / Credit:

Most people fail to understand the thinking behind MVPs / Credit:

When first building an MVP, it really does not make sense to build an app that can cater to millions of users, when you aren’t even sure if you can sign up ten users. On the other hand, building an extremely limited MVP will almost always result in a costly rewrite, in the event the MVP manages to gain traction. In this context, Scalable MVPs constitute a middle-of-the-road approach, and allow developers to limit the effort that goes into building an MVP while leaving the door open for easy scalability, should the need arise.

Even though an MVP is typically developed in haste, adhering to core design principles (SOLID) and best practices is important. When best practices such as separation of concerns, dependency injection, interface segregation, and the open-close principle are already in place, it is much easier to extend the application beyond the MVP stage.

Scalable MVPs and techniques deliver the following benefits:

Horizontal Scalability

A scalable MVP allows developers to manage server loads cheaply and efficiently through horizontal scaling. Compared to vertical scaling, horizontal scaling is less cumbersome and comes with the inherent benefit of elasticity, enabling development teams to add resources as needed. Developers can also turn to orchestration services such as AWS Elastic Beanstalk to automatically handle capacity provisioning, load balancing, scaling, and application health monitoring in the background, with minimal need for human intervention.

However, there is a caveat. Horizontal scalability is largely dependent on the database the MVP or app is built on. If there is a reasonable chance of user numbers growing rapidly, it is important to be mindful of the database’s need to be able to cater to a large number of parallel requests, a common scenario with multi-tenant applications. Therefore it is worthwhile to consider opting for NoSQL databases such as AWS DynamoDB and Azure Cosmos DB that support horizontal scaling out of the box, thus allowing for throughput to be easily increased based on demand.

From a technical standpoint, the difference in performance between a database with 1000 records or 10 billion records is marginal at best. However, NoSQL databases are not silver bullets. As with everything, they do come with some limitations. Designing your data model with a NoSQL mindset is tough, and requires the presence of developers with prior experience. But, paying attention to such factors early on, will make scaling up much easier later on.

Reduced Re-architecting

As an app moves through its cycle of maturity, re-architecting becomes almost unavoidable. However, re-architecting is a tedious process, but if correct principles have been followed in building the MVP, the degree of re-architecting required will be less because performance testing is easier. Once current performance levels and bottlenecks have been identified, the next steps usually reveal themselves. For instance, an MVP that was originally written in Cordova may have to be rewritten in native iOS and Android in order to accommodate a better user experience and features that draw on functionality native to a given device. Since a scalable MVP follows the same logic as building blocks, it becomes easier to decide which components must be developed, modified, or done away with, while making sure that the core functionality of the app remains unchanged in the eyes of the user.

Unit Testing

Once they gain traction, MVPs tend to expand rapidly, adding lots of features within a very short time. This will make it necessary to refactor the existing code, which can be very dangerous. However, scalable MVPs make it possible to carry out unit tests, which makes it safer to carry out refactoring. Writing unit tests does consume more time and would definitely have a negative impact on the delivery timelines of the MVP. But, if the development team has the experience and is comfortable with writing unit tests, it eventually offers great payback allowing the team to both develop and test faster, without getting bogged down in manual regression testing every time they need to release a new feature.

Launching an app and scaling it to handle requests from millions of users is hard. However, using scalable MVPs and techniques from Day One can make life a tad easier.

For more ideas on cutting-edge technology from the minds at Calcey, follow us on Facebook, Linkedin, and Twitter


Transforming Businesses On A Budget With AWS Lambda

Fresh Fitness Food Calcey

Here’s how Calcey helped a London-based food-tech startup transform its business with AWS Lambda

When you think about it, the process of ordering food through an app does seem like magic. A few taps here and there, and voila! Your food is already on its way. But unbeknownst to us, there is a lot that goes on behind the scenes. Take the case of Fresh Fitness Food (FFF), a healthy meal delivery service based in London with whom we have had the pleasure of working. Every day, FFF delivers thousands of bespoke meals to its customers across London.

To borrow a metaphor, if the complexity of a regular meal delivery app can be equated to the experience of driving a car on a busy road, the complexity involved in ensuring a bespoke meal delivery service such as FFF runs smoothly is akin to piloting a helicopter. Every minute adjustment from the user’s end can set off a chain reaction in the algorithm that powers the company.

Like most other technologically powered services, FFF too is powered by an algorithm whose main function is to carefully put together a set of bespoke meals to suit a given daily caloric requirement, which can vary from customer to customer. The actual meals are then prepared accordingly and delivered on a pre-set schedule. At first glance, this looks easy, but when you have to tweak thousands of meals a day, it quickly becomes a nightmare.

On a given day, FFF has to balance and create meal templates for anywhere between fifty to hundreds of new orders. While the existing infrastructure was capable of managing this workload, any change to existing recipes or meals invalidated all previous meal/recipe templates due to changes in the nutrients between meals. This created a need to re-balance and create new meal templates for a large number of orders within a short timeframe, and the existing infrastructure could not cope with this increased demand for speed and simultaneous processing power.

When we first spoke to the FFF team, we found that FFF was running its own legacy meal balancing algorithm on a regular server which was also used to host all their backend IT infrastructure. As a result, whenever the resource-intensive algorithm was run, it slowed things down enormously for the entire company. With the algorithm needing 2-3 minutes to process each order, re-balancing FFF’s full order volume would have taken up to 4 days, and left quite a few Londoners hungry and disgruntled in the process.

Our Solution

Once we realised that FFF’s ability to scale and grow as a business significantly depended on the efficiency of the meal balancing algorithm, it became clear that whatever solution we came up with must also be scalable seamlessly. Since FFF was not a large corporation with deep pockets, we also had to be mindful of running costs.

After careful deliberation, the Calcey team zeroed in on using AWS Lambda to host the new meal-balancing algorithm. AWS Lambda is a server-less service provided by AWS and is used to isolate time-consuming computing activities away from regular IT infrastructure. A process running on Lambda is easily scalable, provided the underlying dependencies can support it.

How AWS Lambda works /Credits: Amazon AWS

In deploying the retooled meal balancing algorithm for FFF, we had to throttle the performance of the Lambda service, in order to ensure harmony with the capabilities of the existing database. But we also gave FFF the ability to increase the number of concurrent executions by increasing the resources available to the database, should it ever become necessary.

Even with performance throttled, Lambda has been successful in speeding up FFF’s meal-balancing algorithm tenfold. What would have taken four days will now take only eight hours. That’s good enough for FFF’s current scale of operations and near-term growth plans. And the operating cost of this dramatic performance enhancement? USD 15 per month. Not to mention the significant cost savings reaped by shifting meal balancing from the existing servers to Lambda.

Our experience retooling a key business process using AWS Lambda is also a great lesson for developers and executives everywhere. Having understood FFF’s requirements, there was no need to overhaul the entire IT infrastructure, as suited-up consultants may tell you. Instead, with a little bit of ingenuity and pragmatism, it is possible to fashion outstanding IT solutions to business problems without burning a huge hole in a company’s budget.

If your business is also looking to move key business processes to the cloud, talk to us and we will be happy to help!

Cover image credits: