Make your product scalable from the onset, without worrying about scalability

Do things that don't scale...or don't?

In 2013 Paul Graham published an article, “Do things that don't scale”, stating that a startup should NOT worry about scalability at the beginning.

Graham then cited some examples of startups that didn't care about scalability, but focused on something else:

• work as closely as possible with the customer
• observe what works and what does not
• iterate the product to satisfy the customer as much as possible

By following this process for many customers, new patterns will emerge that will allow the startup to understand what to focus on.

Only when the product has reached a market fit, then the startup can worry about scalability.

I fully agree with what the article says and I am the first to promote that a product cannot survive without a market.
However today, almost 10 years later, scalability can and must be approached differently (and how I did it - see below).

Why doesn't a product have to be scalable from the start?

I believe this question was valid 10 years ago, but today, with the technologies we have, the question is no longer relevant. 10 years ago, worrying about scalability meant spending an enormous amount of time on:

• infrastructure,
• architecture,
• network and systems issues.

If I spend a large amount of time on these aspects, I will have to take time away from others.
It would be a mistake, especially at a stage where I don't know yet if my product has a market.

The point is that the above continues to be true: the priority must be the product-market fit. The only difference is that today I can focus on product-market fit and still be scalable from the onset.
This is why the question above is no longer relevant: I can approach scalability right from the start, without wasting time, using the right tools.

The psychological factor

There is also another important factor that is often underestimated: the psychological one.

While a business, marketing, and fit-minded person doesn't care about technical scalability, a conscientious developer knows perfectly well that some types of systems, as he/she is developing them, will never be able to scale.
It seems absurd, but this aspect can unconsciously block the progress of a project.

If, on the other hand, I know that my project will be able to serve 100, 1000 or 10000 users at the same time, I have one less problem to worry about. A big problem actually: personally I think it is one of the reasons why some founders often don't push their product further: they are held back by the fear of scaling.
Since it is now possible to create systems that are scalable without worrying about how to implement scalability, my suggestion is to embrace these systems and thus eliminate this fear.

How to scale without worrying about scalability

For those who are not developers, the only choice is to rely on NoCode tools. And there are now so many you can rely on: Airtable, UiPath or Notion are some examples.
The problem with NoCode tools is that when you need to customize them, it's difficult and sometime impossible.

On the opposite side there are the tools entirely developed and deployed internally, based on docker, perhaps with kubernetes, both for the backend, the frontend, and the DB.
The problem with this approach is that you need a person who is entirely dedicated to maintaining the infrastructure, ensuring that systems are always online, and worrying about how to scale if the product grows. Often this person is the product developer himself. And there the fears and problems arise.

The third way is the hybrid approach. With a hybrid approach, the developer can focus on features, customized ad hoc for customers, but without worrying about the architecture, the infrastructure, the network or the scalability.

For the frontend today we have several systems that allow the deployment of automatically scalable frontends: just specify the deploy command and the files that represent the frontend. Nothing else. Some examples are Cloudflare Pages, Github Pages, Netlify, Vercel.

For the backend the function approach is what we need: just focus on the function and the endpoint that will be called to execute that function. Nothing else. Possible providers are: Cloudflare Workers, Azure Functions, AWS Lambda or Google Cloud Functions.
For the DB, once again the major providers offer automatically scalable services for Postgres, MySql, or non-relational DBs. Then there are smaller operators and even providers who use a different approach: care about the DB management in terms of backup, scalability and maintenance on any infrastructure of your choice between AWS, Google and Azure. One of these providers is CrunchyData.

The experience with two of my products: Buglink and Httply

About two years ago I developed a product that is still sold to some companies today. It is called Buglink. Buglink is a bug reporting product that allows you to record a user's session and present it with a video and a devtools like GUI showing past requests, localStorage, sessionStorage, and cookies. The system was developed with docker technology for the frontend, the backend, and the DB (using postgres).

Buglink never needed to scale, but in my heart I have always known and still know that he has limits if he will ever have to scale. And I am convinced that these limits stop me from advertising the product. I prefer to go slow and involve a few companies at a time, which is probably a mistake.

In the last few months I have started extracting a portion of Buglink to make it a standalone product. It's called Httply, it's open source and hasn't been released online yet (but it will be soon).

Compared to Buglink, with Httply I decided to use a scalable approach from the beginning.

The amazing thing is that the development was faster because, after an initial phase to understand how these technologies work, I was able to focus on the functionalities that are really needed and delegate the non-dev aspects to external providers.

I used Cloudflare for the frontend and backend part. CrunchyData for the DB.

I have to say that I was amazed at how easy it is to organize everything and then dedicate myself only to the fun part of the code.
For the frontend, I am only concerned with developing the components and with a command I find the system in staging and / or production in a few minutes. Cloudflare gives me 1M of free requests per day and can scale indefinitely.
For the backend part, once again I can focus on the functions that will be called for a specific domain / path. I can publish with a command to Cloudflare and again have 1M of free requests per day and the ability to automatically scale.
Finally, regarding the DB, CrunchyData gives me a Postgres equivalent to what I would have pulled up with docker, but with the difference that this too can scale up to hundreds of TeraBytes or increase the RAM or CPU load with a few clicks.

Conclusions: "don't worry"

Since technical scalability is no longer a concern, more than “do things that don't scale” I would say “don't really worry about scalability”.
As a software engineer I believe “don't worry” should be a mantra. And not just for scalability. The more I don’t have to worry about something, the more I can focus thoughtlessly on what's important.
Developing software is complex and it is worthwhile to always investigate new solutions to minimize risks and embrace automatic solutions for what previously required a lot of time, resources and energy.

If you liked this story and want to know more about httply or more stories like this, then follow me :-)