In the world of tech startups, your first goal is typically to create a Minimal Viable Product (MVP) based on the entrepreneur's vision, and then attract customers. Following this, you learn, iterate and improve on the MVP.

As shown by the authors in [1], the most popular technological field for startups in 2021 was fintech, the field in which Dintero belongs to. They also show that 9 out of 10 startups don’t survive. 30% of startups go out of business within two years, and 50% have closed shop within five. In other words, a large portion of the failing startups go out of business, even after surviving the initial phase.

So, what is the reason only 10% of startups survive the next couple of years?

From [1], we see the reason for failure is distributed, where the most common ones include no market need, running out of cash, wrong team or team composition, competition and pricing.

There can be countless problems behind any of these, and even more solutions to solve them.

However, in this article we will focus on one concrete aspect that we claim influence all of them, and that is the ability to scale.‍

‍

When the word "scale" is used in this setting, it is often used synonymously with growth, and in the realm of startups, scaling happens along many different dimensions, such as revenue, funding, customers, employees, market share etc.

Growth along all these dimensions is very important for the long term viability of the startup, and thus using methodologies, technologies and strategies that enable Scalability is crucial.

However, scalability isn’t easy, as Elon Musk so famously said: ‍

“The extreme difficulty of scaling production of new technology is not well understood. It’s 1000% to 10,000% harder than making a few prototypes. The machine that makes the machine is vastly harder than the machine itself.” - Elon Musk, Twitter, sept 22. 2020.

‍

Scaling isn’t only difficult when scaling the production of electrical vehicles, it is also hard when scaling software solutions, where early decisions in the development process often dictate the scalability of the product in the future.

Armed with this insight, scalability will always be a central aspect of all technical decisions at Dintero.

In the rest of this article we touch briefly on some of the technical decisions we’ve taken to enable us to scale moving forward.

Infrastructure as Code

Among several positive aspects of defining your infrastructure as code, you improve the ability to scale your services to new geographical areas without much friction and work.

At Dintero we use AWS Cloudformation[2] to define our infrastructure running as AWS cloud services. In addition to scalability, defining your infrastructure as code gives you the ability to move all services to a new region in cases where the current is unavailable, requiring only a miniscule amount of work and time.

‍

‍

Microservices Architecture

All Dinteros features are distributed among services in the familiar microservices architecture, where each service maintains a high cohesion and the coupling between them are kept low.

This type of software architecture improves our capacity to add new features without influencing existing ones. It makes the job of changing existing features a lot easier, since the features are separated from one another. Additionally it provides us with the capability to scale throughput only where it is needed. 

‍

Serverless computing

Even though defining the infrastructure as code and using a microservices architecture improves scalability, there is still a time and personnel cost related to scaling the hardware used by your infrastructure. A prominent solution to this is to use what is called serverless computing.

In serverless computing, the allocation of machine resources is performed by the cloud provider[3]. 

Thereby, the resources available to your services are scaled based on demand, i.e, reducing the cost during periods with low demand, while still maintaining high availability during peak loads and bursty scenarios.

At Dintero we use serverless services provided by AWS[3], among those, we use lambda, fargate, dynamodb, SQS, SNS and more. In a future blog post we will showcase specific use cases where these services have been employed to improve the scalability of our services.

Clean Code and Readability

The last strategy we want to touch upon, which also supports scalability to a large extent, is the user-friendliness of the codebase. In startups, as previously mentioned, the initial goal is to create a solid MVP. And then to grow and improve this first iteration of the product at a high pace. The MVP is, as the name suggests, a temporary, functionally limited, version of the product, i.e, only the most essential features of the product have been implemented. The consequence of this is that the product will most likely undergo large changes in the future.

As all experienced developers know, making changes to existing code can both be a delightful and a horrible experience. This often comes down to the user-friendliness of the codebase. Here, the user refers to the developer working on the codebase. All the aforementioned scalability strategies also help when it comes to user-friendliness, e.g. using a microservices architecture.

However, it is also important to make sure that, within each service, the code is properly modularized, where each module has a high cohesion and the coupling between the modules is low.  Additionally, we claim that the readability of the code itself is of utmost importance.

When the startup is scaling, new features are added rapidly, older features are being drastically changed and new developers are hired. A codebase that is easy to understand and use is essential for the scalability of the product.

[1] https://firstsiteguide.com/startup-stats/

[2]: https://aws.amazon.com/cloudformation/

[3]: https://aws.amazon.com/serverless/