Technical Tradeoffs are Inevitable

Technical Tradeoffs are Inevitable When Scaling a SaaS

—-

Prior to founding Balio, I founded an attendance and payroll software company in Southeast Asia. In the very early days of the company, where resources were limited and product-market-fit was yet to be reached, we iterated extremely rapidly on the product using a slick stack of tools: a no-code tool to build the mobile app powered by a Node.js API that leveraged a no-code spreadsheet tool called Airtable as the backend database.

It worked wonderfully up to a certain level of scale. However, once we started acquiring a few hundred users a day, it quickly stopped working. Creating and managing monthly and weekly pay cycles for that scale of customers just wasn’t feasible with the tools we were using. We migrated to a proper Postgres database soon afterwards.

However, we ran into further issues as a few hundred users became a few thousand users. Our servers got flooded with long-running requests at the end of the month when users tried to use our PDF payslip feature. We once again had to modify the rendering algorithm to ensure it worked at high-speeds. The solution we built never ended up being changed after that.

Running payroll calculations also became increasingly challenging. Payroll in countries like Indonesia can be notoriously difficult to compute and manage and users needed near real-time calculations based on a variety of rules (sometimes based on attendance, sometimes not or attendance-based allowances). We had to design a variety of mechanisms (batch calculations, caching, etc.) to solve that bottleneck.

As we got to tens of thousands of users and had to handle larger volumes of payments, payment operations became an important part of our company: KYCing users, handling payment failures, etc. We had to build a system with a variety of guarantees as transactions occurred. This involved building queuing systems, approval workflows, and more.

What’s the takeaway in all of this? Engineering challenges change as companies scale. What’s painful at a lower scale of users might be completely different than what’s painful at a larger scale. Code and systems that work for a small number of users may completely break when the user base grows by 5x. Most of the time, you can’t even anticipate what engineering problems will emerge in the future.

But that’s okay. In the early days, trading off scalability for speed is usually the right decision–you need to ensure your company is solving a real problem that people will pay for as soon as possible. What’s critical to understand is that this tradeoff comes at a cost: you need to pay back your technical debt, with interest, as the company scales. 

Being deeply in tune with the technical tradeoffs made in various stages of product scale can help you prepare for fast growth. Regardless of whether you’re a coder or not, what I’ve learned is that it’s always good to know why you built the product the way that you did!