How to Lower Your SaaS Engineering Costs

At B2B SaaS companies, Engineering spending is on the rise — the percentage of software company revenue allocated to R&D is up 20.6% in 2020 and is unlikely to stop in a market characterized by constant innovation and Product Led Growth (PLG).

In an increasingly crowded market, SaaS companies that can be more efficient with their Engineering spend will have more freedom to innovate and grow. But how can you reduce SaaS engineering costs without sacrificing the product quality and reliability that your customers expect?

In this guide, I'll show you how to conquer your engineering costs while simultaneously enhancing your software development process. After implementing these strategies, you'll have a cheaper, more reliable product that will increase your customers' confidence in your brand. Some nice side effects of this include reduced churn and improved Customer Lifetime Value (CLTV).

First, we'll examine how to reduce the biggest engineering cost of them all: maintenance.

The Source of Most SaaS Engineering Expenses

When budgeting for growth, it's vital to realize that most of your engineering budget will be spent on maintenance — it's over 90% of spending now, up from 50% in the 70s. You'll be spending this money paying engineer wages just to keep your product running, with almost nothing left over to enhance your product or add new features.

Software Maintenance Costs

Source

Why is this number so high?

Partly, the rise in maintenance is because there wasn't much software in the 70s. This was a time when you could map out the Internet on a single piece of paper. Compare that to today's proliferation of software tools everywhere you look, from banking to building, and it's easy to see that there's a lot more to maintain.

But for the most part, the increase in maintenance activity is due to engineer mobility and a lack of documentation, meaning that the people who knew how everything worked at an organization left without writing it down! This fact is clear once you realize that over 50% of software maintenance cost is spent on analysis, rediscovering lost knowledge about software systems that engineers took with them when they left the company.

Software Analysis Costs

Source

So now that you know where your engineering costs are coming from, how can you minimize them? One of the best ways is to build your product with a small, highly-experienced team and stick with them as long as possible.

What makes this type of team so effective at keeping costs down?

They've encountered every type of problem before. Your engineers must have the seniority and breadth of knowledge necessary to get you through the full variety of challenges you'll face. They're not junior engineers who, while cheaper, but don't have enough experience to see expensive mistakes coming.
They're efficient. Small teams reduce coordination and communication costs between engineers. Because of Conway's law, small, simple teams are more likely to produce simple, easy-to-maintain software.
They won't disappear on you. Sticking with the same engineers as long as possible lets you retain the undocumented knowledge about your software system that only exists in your engineer's heads.

However, the senior engineer is a rare breed these days, and demand for them is high. So it can be challenging to keep them in today's job market (even despite the pandemic).

To increase your odds of keeping engineers, treat them as autonomous, well-qualified partners. That means actively sharing all relevant business details and company performance with them. Recognizing engineers as creative problem solvers, not just mindless drones, is one thing that Silicon Valley startups consistently get right.

Team Autonomy

Source

It's also vital to ensure that your engineering partners have a long-term interest in your success. You don't want to work with people who will jump ship as soon as another exciting gig comes along, taking your product knowledge with them. So avoid hiring low-cost engineers or short-term freelancers, only to part from them and be left with a product that no-one in your organization understands. Get the most capable and versatile engineers you can afford and never let them go.

Research completed by Notion Capital Managers backs up these conclusions. They found that a key differentiator in post-series A startup growth rate was hiring: faster-growing startups hired more senior people for all roles, paid more for them, and hired them earlier in the process.

Technical Leader Years of Prior Experience

Source

Of course, it's not always possible to keep engineers indefinitely, especially when quality engineers are in such demand. So as insurance, make sure to document your entire software system, ideally within the source code itself. This ensures that any future engineers you hire will be able to understand what you've already built.

I'll touch more on documentation later, but first, let's see how you can find the best engineers without spending a fortune.

Save on Engineer Wages

Since most of your Engineering costs will come down to engineer wages, it makes sense to focus on optimizing those. So how much should you be paying for competent engineers? And is it safe to hire from abroad to save money?

US Engineers vs. Global Talent

Depending on your location, available talent, labor regulations, and other factors, SaaS engineering costs vary sharply. Engineers in the US are typically well-paid, with the average software engineer salary hovering around $92,000:

US Engineer Salaries

Source

But the highly-capable engineer you hire to build your product doesn't have to be an in-house employee, any more than the software you rely on has to be hosted on your own servers.

Software Engineer salaries are markedly lower in other countries — somewhere around half this in the European Union, and lower yet in Finland and Estonia. Head to India or Bangladesh, and you'll see rates plummet.

One reason for this wage differential is the greater demand for highly-skilled engineers in the US. More companies are fighting for the best engineers, and there aren't enough to go around. It's much easier to become a rockstar engineer if you can easily commute to Mountain View or New York than if you live an hour from Helsinki.

Another reason for lower wages abroad is cheaper cost-of-living expenses and social benefits. Typically, employee benefits account for 30% of a US employee's fully-burdened cost. Additionally, US engineers might be paying Bay Area housing prices and face higher out-of-pocket expenses, so they'll need to be paid more to offset this. Add to this supervisory costs, office space, and equipment, and your total cost can end up well over $100 per hour per engineer.

Contrast this with European engineers who rely on national safety nets and more livable cities to reduce their expenses. They can spend less out-of-pocket since they benefit from universal healthcare programs and cheaper education.

So from a US company's viewpoint, offshore engineers are certainly a lot cheaper by the hour, benefits included. But what about their skills? Will you find engineers with the expertise you need in Berlin or Tokyo? Or should you stick to Silicon Valley?

Which Country Has the Best Talent?

If we rank global university Computer Science departments by published studies, US universities make up the top 8 positions. Clearly, the US is a leader in Computer Science research.

However, you can still find world-class engineers in places like Switzerland, Canada, Poland, or Taiwan.

Which Country Has the Best Developers?

Source

So why would you look abroad if you have so many great engineers close to home?

Besides cost, one thing to consider is that different regions specialize in particular technologies. For example, you'll find plenty of FinTech experts in financial centers like London or Singapore. Privacy-centric Germany is known for its cybersecurity professionals and Taiwan for IoT specialists. So consider your desired skillset carefully before deciding where to hire.

The bottom line is, US engineers aren't necessarily better, and offshore engineers aren't necessarily worse. There are a variety of factors to consider, including cost.

But before you rush ahead and hire offshore, it's essential to prepare yourself for the challenges. Getting outsourcing wrong can lead to costly errors and rework, ultimately costing you more than if you had just hired in-house.

Navigating the Outsourcing Minefield

We know that most engineering costs are caused by engineers leaving your organization and taking their knowledge about your software with them. One way around this is to hire engineers that will stick with you as long as possible.

But finding long-term hires in the world of outsourcing can be difficult if you don't know where to look. While you might have luck finding freelance engineers on platforms like Upwork or Freelancer, the nature of the gig economy means that most of the candidates you'll find won't have long-term dedication.

A better option is to work with a small SaaS development agency or SaaS product studio accustomed to building and maintaining their client's products for years.

The advantage of working with a trusted partner this way is that you get the benefits of outsourcing combined with the convenience of a managed team, without the downsides of hiring in-house: no recruiting costs and no employee benefits.

Most importantly, you get the additional guarantee that your engineering process maintains some permanence. Working with a partner studio ensures that all engineering processes will be documented and maintained as part of your partner's institutional knowledge.

But having a great engineering team isn't enough to minimize costs. Next, we'll look at how to structure a low-cost, high-performance engineering process and how SaaS-centric engineers fit into it.

Improve Your SaaS Engineering Process

SaaS engineering isn't like classical software engineering. There's a big difference in how you should approach the oft-cited "Iron Triangle":

Good, Fast, Cheap - Pick Two

Source

This is a convenient way to think of SaaS projects and a striking image. But it's a gross oversimplification — that the triangle graphic doesn't even mention scope!

There are actually six things to consider when undertaking a SaaS project:

Scope
Quality
Time and cost
Cost-benefit
Benefits
Risk

Six criteria are harder to draw than three. Still, an assessment that considers expected benefits, project scope, and risk is much closer to what you need to know to make good decisions.

What Makes SaaS Engineers Special

In fact, scope is the most decisive difference between SaaS engineers and traditional software developers. A conventional developer can deliver late if the quality is high and the scope is met. The SaaS engineer doesn't have that luxury:

...if you're building a SaaS product, you need a certain breed of engineers. And the main quality is to be on time. So you have this triangle, when you build something, you have "scope", how much you're willing to compromise and what ships in the final product. You have "time" and you have "quality". You have to find people that are willing to compromise on scope. So you have a quarter, the team has to ship something by the end of the quarter, and they have to be product-minded enough to realize what is optional and what can be cut and still have a relevant product at the end. -- Laurent Perrin (my emphasis)

SaaS engineers need to be dynamically updating the scope in response to time and, to a lesser extent, other constraints to make sure they're ready to ship on time. And they have to be able to do it without compromising quality or reliability.

Lower Costs by Focusing on Quality

To save money in the long-term, build structures and processes that help you focus on quality and reliability. These structures pay off at every stage of production and, more crucially, during maintenance. Maintenance is 90% of software costs, remember — don't try to save a buck on initial development, only to pay it out nine times over down the road. Instead, build for easy upkeep and fixes.

That means clean, high-quality, well-annotated code. The acid test should be: if a good engineer who has never seen this application before came to work on it tomorrow, how soon would they be able to start contributing? You want to get this time to the absolute minimum and keep as much of the information the new engineer needs within the codebase itself.

Most engineers spend five to ten times more time reading code than they do writing it. One of the leading barriers to productivity for new engineers is that they step onboard and have no idea of your code's purpose. They'll understand what the code is doing, but how will they know why you needed that code in the first place?

Encourage Maintainable Code

Annotated, human-readable code slashes preparation time and accelerates productivity, wasting less of your most valuable and expensive resource: engineer time.

Have engineers focus on creating code that other engineers find easy to read, understand, and maintain. This type of discipline will save you vast swathes of debugging time and translate into lower costs and a higher ROI.

To that end, consider using a tool like ExDoc to turn code comments into easily-readable HTML documentation. This practice has the added benefit of keeping documentation from going "stale" since it sits directly within the code it annotates.

Use a Linter

Linters are like spellcheckers for code; they catch bugs and weird-looking syntax, enforce stylistic and best-practice rules, and generally automate the process of keeping your code on the rails.

Credo Linter for Elixir

Source

Review Code Regularly

When you have a team of engineers, start doing regular code reviews. The standard should be code that an engineer can approach "cold" and still understand. Doing routine checks means you get better, more maintainable code. It also spreads a consensus among engineers about what constitutes good code and can form the basis of a company code style guide.

Engineers should do code reviews before merging new code with the main codebase; this is another ounce of prevention that's worth a pound of bug-fixing cure down the road.

Conduct Pair Programming

Once known by the slightly cringy "Extreme Coding " moniker, this is now standard programming practice. It might seem odd to suggest that as soon as you have two engineers, one should watch the other one work. Still, it makes code editing and writing a single, simultaneous, much faster process. It's also an opportunity for engineers to share knowledge across specialisms and seniority.

Write Automated Tests

Automated tests are pieces of code that test your application's code, simulating customers using your product. They're capable of being much more thorough and much faster than manual testing.

Engineers can run automated tests across the application every time new code is merged with the main codebase; in a modern product team, this can be dozens of times a day. Even full-time manual testers can't work that fast, but automated testing can flag bugs on the fly.

Automated tests won't tell you much about the subjective human experience of using your product, so manual testing is still essential. Nevertheless, strictly for keeping code working, automated testing is crucial.

Use CI/CD

Use a Continuous Integration / Continuous Delivery (CI/CD) service like GitHub Actions, Bitbucket Pipelines, or Jenkins to deploy your code. Engineers push their code to these services. Then the service runs all the linters and other mandated tests to check the code's quality. Then it automatically packages the code and deploys it to servers.

GitHub Actions

Source

This lets you build all your Quality Assurance processes directly into your routine without engineers having to think about it as an additional task. A complex, unstable, and error-prone process becomes a fast, robust, and predictable workflow that's easy to oversee. This saves hours of engineer time in production and achieves better, less buggy code that requires less maintenance and repair.

Use Staging Servers

Test all new code on staging servers before taking it live to production. Staging servers should be identical to your live servers, allowing you to test the product under near-identical conditions; this includes performing strenuous, potentially destabilizing tests you wouldn't want to risk on your live servers. A final round of bug checking and performance testing under real conditions, like a full dress rehearsal for your code, lets you catch problems and fix them — before a user catches them and Tweets them.

Hire QA Engineers

If you've moved beyond your MVP stage and you're running a small team, you should consider having a dedicated Quality Assurance engineer whose whole job is to manage, test, and ensure code quality.

This person isn't a replacement for automated testing and inline QA. Neither are those processes any substitute for a talented and capable engineer adversarially testing their colleagues' work until it breaks. This level of quality control will cost you the salary of one engineer and save you the salaries of dozens spent maintaining and repairing buggy code.