CTO's Journal: Death by scaling

March 4, 2022
CTO's Journal: Death by scaling

CTO diaries: Part 3

Life swings like a pendulum between pain and boredom, said Artur Schopenhauer, often mistaken for a pessimist. When we are comfortable, we strive for challenge. When we are challenged, we long for comfort, never able to stand still in this construct called happiness. Unknowingly, Schopenhauer also laid a great metaphor for one of the most complex topics in tech: Scaling.

I like to think of scaling as a pendulum that swings between generalization and specialization. When you find a solution that works for a group of customers, you must work on generalizing product and infrastructure to a wider audience — at the same time, once you capture a wider audience, you must drill down into specifics that will improve your offering to each individual customer group.

If you fail to generalize, you don’t grow. If you fail to specialize, you become a lukewarm solution that fails to awe, and thus an easy prey to be eroded by competition.

Scaling pendulum

Needless to say, product scaling must also be accompanied by a corresponding scaling in infrastructure, which opens up a whole new level of complexity, as it can quickly lead to suffocating economics or plummeting service quality.

Airbank is now closing in on a thousand onboarded companies spread across multiple European countries, which points to a clear diagnostic: We are scaling.

Scaling is a pendulum that swings between generalization and specialization.

In this third chapter of the CTO diaries, I’ll be addressing questions that we face at Airbank every day, such as: When is it time to generalize or specialize? How do you find the right balance? How to coordinate product and infrastructure scaling?

But first, let’s take some inspiration from the most successful scalers in the world.

A lesson from molecular biology

As some of you know, my background is in the medical sciences. I used to spend my time developing computational models for molecular evolution (how I got from this to building the future of business finance at Airbank is a story for another post).

As a matter-of-fact, biology is all about scaling. It happens in multiple levels simultaneously, through the prism of evolution. Competition for resources and scaling happens between species, between different populations of the same species, across individuals, but also on a cellular and molecular level, as beautifully explored in the book The Selfish Gene, by Richard Dawkins.

If you think about cells as individuals, then cancer cells might be the most skillful ones at scaling. They successfully break free from the growth limits imposed by their surrounding tissues, dribble around our immune system (aka regulation), and are able to multiply in speeds otherwise unattainable, storming other tissues and creating uncontrollable colonies.

Darwin defined fitness as an individual’s capacity to reproduce, generating viable offspring. So an interesting reflection is: Do cancer cells have higher fitness than normal cells? Mathematically, yes. But of course, if one looks at evolution from a more macroscopic angle, it would be possible to argue that, ultimately, their uncivilized scaling reduces the fitness of the overarching individual.

A lesson from molecular biology for CTOs meme

In order to avoid this stalemated outcome, we may instead look at unicellular organisms, such as bacteria. Their scaling primarily happens across three dimensions: Spreading to more hosts, spreading to more viable hosts, and spreading more inside each host. These forces act in parallel, guided by the invisible hand of evolution, ultimately defining the success or demise of a bacterial strain or species.

Interestingly, we can use the exact same dimensions to think about product scaling: More customers, larger customers, and more relevance for the same customers.

Businesses that scale successfully know how to balance investments across these dimensions. I’m talking about product decisions, marketing efforts, brand positioning, and obviously also infrastructure (after all, this is a post from the CTO diaries).

There are 3 dimensions in which your product can scale. More customers, larger customers, and more relevance for the same customers.

Let’s explore each of these dimensions more carefully, taking examples from Airbank and other startups.

Scaling to more customers

The most obvious type. Every company, from enterprise software to dating apps, has onboarding more customers as a primary business goal. This type of scaling is a metonymy for product-market fit, with businesses focusing on achieving predictable acquisition costs.

Ultimately, scaling to more customers means identifying elements that indicate the right targets, and then reaching as many as you can. Therefore, one of the key pre-requisites is having a lot of insight on who your potential customers are, where they are located, and how to successfully reach and convert them.

The pitfall
To onboard significantly more customers, one has to broaden their vision, feature coverage, and even brand identity — which can lead to over-generalization (as per the pendulum). Too often have we seen startups that were successful in their early traction, but then flew too close to the sun in a desperate attempt to embrace the world, watering down their initial success and ultimately either failing, or having to back off. A recent example is N26 and their unsuccessful entry into the US market.

Scaling to more customers meme

The tech challenge
More customers implies in more users accessing your services at the same time. If this expansion also includes new geographies, you’re in for a real treat when it comes to evolving your company’s infrastructure. In terms of compute resources, depending on how they are structured, you may face costs that grow step-wise (e.g. additional VMs), leading to economic gaps (the distance between the ideal amount of computing and the deployed infra). Ultimately, you’ll face the dilemma of vertical versus horizontal scaling (more CPU/RAM on the same VMs, or additional VMs). In terms of storage, if you use relational databases and need geographical replicas, it’s time to hire a database manager and start learning more about sharding, unless you go for a serverless, fully-managed solution like Fauna (which I do not recommend, as per CTO diaries: Part 1).

Scaling to larger customers

Ah, the enterprise customer. How much we all would love to boast about big names using our product on that logo board at the very top of the website. Besides, larger customers also tend to be less prone to churning (for them, getting rid of a software provider is almost as hard as adopting a new one). So better credentials and economics, what could possibly go wrong?

The pitfall
To onboard larger customers, one has to invest in non-scalable value propositions, such as high-touch sales and service, high product flexibility, and specific integrations that are really hard to get right — and with less customer granularity, mistakes cost more, and maneuverability is decreased. In other words, it doesn’t favor either side of the pendulum, but it makes it swing slower, which can bring your entire organization to collapse due to faster competitors or difficulties in adapting to market changes (e.g. regulation, new technologies, new market entrants). When you ask yourself why large enterprise software providers don’t evolve their hideously outdated, clunky UIs, this is a big part of the answer. Think of SAP, Salesforce, Oracle, or worse, AWS.

Scaling to larger customers evergreen meme

The tech challenge
Serving large customers usually means 3 things: Having to abide to SLAs (especially if you are an API provider), having to offer enterprise features such as SSO, and having to offer multi-tenancy and/or on-premise storage. Each of these elements hides a world of complexity. SLAs means that, from now on, every tech mistake you make will contractually cost you money. Enforcing quality can be very challenging depending on how your services are structured and how good your team is. Then, building enterprise features demands a whole new level of flexibility and attention to detail: Large customers have very specific requirements, and once you have a few of them aboard, you’ll realize that building a single tool that caters at all of their whims is very complex, especially from a UX perspective. Finally, if you haven’t prepared beforehand for multi-tenancy or on-premise, you are once again in for a really special treat, as evolving your database structure will likely demand months of work (in which you won’t be able to onboard those large customers), and will then require a whole team to manage.

Scaling to more relevance for the same customers

Relevance can mean many different things. Going deeper into specific features, getting a larger share-of-wallet, more use time through directed content. It all depends on what you offer and who your customers are. This dimension is all about depth, which ultimately opens the doors to monetization and loyalty, while also raising barriers against competitors.

The pitfall
You’ve guessed it. The pitfall here is over-specializing, which ultimately leads to becoming a niche provider instead of a massively scalable solution. And it isn’t just bound to product/tech: Once you start specializing on specific customers, they become the basis of your revenue and marketing efforts, while in other customer groups, churn and customer acquisition costs tends to increase. Eventually, you are so bound to that group you focused on that you just can’t find a way out without sacrificing revenue, worsening unit economics, and undergoing a massive shift in market perception and communication. A great example here is Firebase: While they set out to become the all-in-one backend-as-a-service for any application out there, they failed to gain traction in the SaaS market, and it’s in mobile apps where they found love — which ultimately led to the creation of a whole new category-defining name (MBaaS), and a much more successful product roadmap.

Scaling to more relevance for the same customers meme

The tech challenge
Here, the main challenge is not necessarily technical (as it depends on what kind of feature you’re building), but rather in product management: How are you going to juggle working on your company’s overall roadmap with the new-found need to go deeper into certain topics? The old pareto principle applies once again: You can build a feature that is good enough for 80% of the use cases with 20% of the time/effort — but to close that gap, things get really sour. We’re talking about UX miracles, specific integrations, small automations, and so on. The key to cracking this is having a great process of customer research, because blindcoding has a 100% fatality rate.

Finding the balance

Unlike bacteria, companies aren’t guided by the invisible hand of evolution (although there may be an interesting investigation to be done on inherent market dynamics that act according to evolutionary math). Instead, we must develop our own strategies and face off against competitors, regulatory landscape, and shifting customer requirements.

Scaling to more customers demands having great insights into what constitutes potential targets, and it’s a great move for companies whose primary goal is proof of PMF, cost dilution, or simply more market relevance. Scaling to larger customers is a bold move that demands already having enough structure in place (sales, tech & support), and being able to fund the longer cycles and on-demand customizations. It ultimately pays off in lower churn, better credentials, and in many cases better economics. Finally, scaling to more relevance for the same customer base is an act of specialization that demands having a solid understanding of what these customers really need, and why these are the right people to bet your efforts on. It is a great strategy for companies that are looking for a stronghold for monetization (who knows, even making a profit), and helps raising barriers against newcomers.

Connecting the dots meme

At Airbank, we have multiple paths of scaling ahead of us. Different geographies, larger customers, new customer groups, deeper functionality within existing features, new features, and so on. Our priorities are defined according to our understanding of the B2B finance market dynamics, as well as our customers’ needs: First, we build a solution that is generalistic enough to achieve expressive traction, but specialized enough to build continuous usage (see more on CTO diaries: Part 2). Then, we build deeper functionality in the features we already have (dimension 3), in order to kick off monetization and fend off competitors. Simultaneously, we invest in new features that act as major customer hooks (e.g. payments, cards) to expand our footprint in the market. Finally, once we are a de facto all-in-one finance management platform with thousands of companies using it on a regular basis, we go after increasingly larger companies, leveraging the gained experience and more mature product/team.

Building a scalable tech setup demands adopting tools and technologies that save developer time, avoid errors, and are able to grow with your product.

Going serverless through Google Cloud Run certainly was the right decision for such a complex product like Airbank, especially considering our competitive market where feature speed and unit economics must be under constant watch. It not only allowed us to convert essentially all compute resources to variable costs, but also offers several advantages on team management (no need to hire and train a back-end ops team, meaning we can focus our money on developing things rather than managing infrastructure).

Other successful decisions we made at Airbank with tech scaling in mind were the adoption of TailwindCSS, which makes managing complex, cross-app design systems with a large team a breeze, and the choice of GraphQL over REST for the API, thus simplifying the creation and evolution of complex queries and mutations. I could also point out the adoption of TypeScript on the API as a key driver of tech scaling, given the tighter control that avoids common errors and simplifies debugging. Finally, using Prisma also makes managing relational databases at scale much simpler, through their beautiful migrations and schema definition file.

Airbank is uniting finance management into a single platform. We have a growing team of 40+ people, fully remote, but with major hubs in Berlin, Vienna and Barcelona, and are backed by some of the greatest fintech investors in Europe. If you’re interested in being part of this journey, shoot us an email.

And obviously, stay tuned for more CTO diaries!

Get started with Airbank today

Managing your finances doesn’t have to be a headache.
Set up your account (for free) and see it for yourself in less than 15 minutes!
Thank you! You can now complete your sign up.
Oops! Something went wrong while submitting the form.