Knowing When To Scale

Recently, I was working on an application that required multiple repetitive tasks to be activated all at once. These tasks would be fairly simple and would require a user to have logged in as well as access to a hosted database to store all the details. Without getting into too much technical detail, there are multiple tools available to help me scale this process to millions of users. That’s when things can sometimes spiral out of control.

As a curious engineer, my immediate thought was to explore the possibility of micro-services and hosted serverless functions to extract this process from my main application. In short, this means I would need to split up my application in multiple places to make things faster (much faster).

This would allow the application to process multiple simultaneous tasks all at once, without skipping a beat. In other words, thousands and thousands of users can press the big red button at the same time.

It was at that point that I started to question my decision. In theory, using all these tools might sound correct, but is it the right thing to do right now? Am I thinking too far ahead? Most likely.

To remain consistent, let’s assume we are building a web application.

What stage are you at?

Determining which stage you are currently at, is the first step to establishing which tools are required to move forward. Not only in terms of your application, but for the business as a whole. Many, many engineers will try to build their application to handle millions of users when they haven’t launched a product yet.

If you are currently in beta with 600 users testing the application, there is no need to handle 100 000 concurrent users. Take your development step by step, while following the needs of the business at that point in time.

Time is your most valuable asset in the early stages of building your application — you should always consider how much time you are spending towards its optimization. Simultaneously, you must evaluate how much time you will need in the future to come back and fix everything.

What’s your North Star?

Every startup has a North Star. What is your North Star, and towards what are you working? This question should help you identify what is more important to the business at the moment. It’s essential to keep your North Star in mind, and never lose track of why you are building this functionality.

It’s always easy for a founder to say “Our competitor uses ElasticSearch, we should start implementing it too.” If your time is better utilized on another feature for the application, it’s important you voice your concern with the team. Otherwise, you might end up over-engineering in areas that won’t benefit the business in the long run.

Use the tools you already have in your toolbox

It’s easy to read an article about machine learning and assume your application needs it to survive. If your application’s core functionality does not rely on machine learning to function, start looking into hosted tools and APIs to make your life easier. You can easily implement Google APIs to solve your problem.

That’s just an example, but the point is that you should always consider the tools already available to you before trying to reinvent the wheel. This can help you move quickly and build the functionality your users are really looking for. Hosted APIs and SAAS applications are extremely useful at any stage of building your application.

Always be planning

While you are building all these amazing, groundbreaking new features for your application, you must always consider the areas that might need future revision. Don’t intentionally add in problematic code you know is a problem unless you have no other option. You are just asking for problems later down the road. Sometimes, things can get scary…

getData(function(x) {
    getMoreData(x, function(y) {
        getEvenMoreData(y, function(z) { 
            getEvenMoreData(z, function(wow) {
                // I forget where I was going here...
            });
        });
    });
});

If you do add something you aren’t exactly proud of, please document everything. Whether you add some @todo comments in your code or you add it to a public to-do list in your repository’s readme file. Just make sure your team knows this is a temporary solution and we need to keep an eye on it.

Good problem to have

At the earliest stages of your startup, traction is probably one of the most motivating factors for your team: more and more users keep coming in droves, and you’re starting to feel the burn. This is a very good problem to have!

Once you have both product-market fit and consistent growth, you can start planning the next steps for scaling your application. There are tons of tools out there to help you measure exactly what is slowing down your app, causing bottlenecks or even failing for some users.

Where to begin?

This is the first of many posts covering scaling and tooling for software startups. We hope to cover many topics, including MVP building, tools for scaling, planning for scale, and more. This is where we will get into the nitty-gritty details of building applications.

We’d love to hear from you. If you have any subject ideas, questions or comments, please feel free to “clap” and comment below!