Scaling Only Matters if You Have Something Worth Scaling

Scaling too early

Engineering teams often focus on scaling a product before they have a product worth scaling, or even know if they'll need to scale it.

This is called "premature optimization", and it kills projects.

Focus on building something that delivers value first, and figuring out how to scale it second. If you don't nail step one, you will never get to step two.

This sounds simple, but it's actually very hard due to "performance shaming":

"Your app is nice, but you built it with Python? That's cute. I could implement that in rust and it would be 100 times faster."

("Yes, but your Rust implementation is going to take 5x as long, and no one on our team knows Rust, so we'll have to spend months training instead of adding features")

Our reputations as engineers are our meal tickets. If we feel like our colleagues are thinking less of us because we don't use a "real language", it can drive us to choose languages which are less productive and harder to use, because we believe that:

"ability to work in a hard language" + "creating code that runs fast" = "good at software development"

In reality, the things that make a really good software engineer are much more complicated and harder to measure.

How to approach scaling your project

1. Accept that most projects/startups fail because the team couldn't build a valuable enough product

   NOT because the product failed to scale. If a product takes off and is successful, money and resources will usually become available to improve it.

2. Choose tools that are fast enough for the problems that you know you have right now

   Choose tools that are productive instead of fast, provided they are fast enough. Language speed/performance is easy to benchmark. Language productivity is more important.

3. Focus on creating an excellent product

   Don't focus on scaling, focus on adding features and making the product valuable enough

4. Avoid coding yourself into a unscalable corner

   When the productivity cost is low, make decisions that will allow for future scaling if needed.

   For example - When building a web app, have user uploaded files stored in an object store, instead of on disk, so your servers can be stateless.

   This will enable server load balancing in the future, while costing very little in development effort (assuming you're using a language/framework with a good ecosystem and library support).

5. Scale the things that need to be scaled, when they need to be scaled

   When you hit a real performance limitation, or you've accumulated enough concurrent users that your application/service is about to have problems, then you should put effort into scaling.