Practical Finance for Software Engineering | Part 1: Understanding Variable Costs and Fixed Costs

Or “Finance Wants You to Give a Forecast and What You Can Do About It.”

A guide for engineering directors, the occasional engineering manager, and the rare software engineer.


Congratulations! If you are reading this guide, you probably work for a company that has found product-market fit and is starting to worry about Cost (Of Goods Sold). You have successfully navigated the turbulent waters of the tech industry, narrowly dodging the likes of WeWork and Quixey. You made it. Give yourself a pat on the back.

This guide will be focused on:

  • SaaS companies, but generally applicable to any tech company

We are going to be hand-wavy on some of the details, but it includes sufficient nuance for the everyday practitioner. If you have an MBA or work as an accountant, you will not like this guide.

Engineering leaders get these questions from time to time:

  • We spend $100K a month on storage. Is that expensive?

Part 1: Understanding Variable Costs and Fixed Costs

We don’t make any profits, so we make up for it in volume.

While that is a funny joke to make, it is time we get beyond trivial humor.

Let’s start simple. When building and selling a product, we incur fixed costs, and variable costs:

  • Variable costs increase proportionately to the number of product units you sell. The more units you produce, the more you have to spend on parts, compute, and customer support. If you are using Autoscaling Groups on AWS, the costs of running those ECS tasks or EC2 instances are variable costs.

Depending on your context, a “product unit” can be a subscription, a license, a ride, a loan, a card, a night’s stay, 1m page views, or an actual piece of hardware.

Formulation: let

  • n be the number of product units sold,

Key Idea 1: as n increases, if r(n) grows faster than v(n), r(n)−v(n) will eventually be positive. This does not mean you are making money (yet), but it means the business is starting to look viable.

Fig. 1: f, v(n), and r(n).
Fig. 2: Same as above, but with somewhat naïve economies of scale taken into account. In some cases, The Law of Diminishing Marginal Returns can become relevant e.g. when you hit infrastructural bottlenecks and need to start investing in something like multi-region sharding.

(Illustrated using Google Colab. Feel free to make a copy for your own presentations.)

Mapping these to terms you might hear from other parts of the business,

  • r(n) is also known as Revenue

There: finance demystified. Hopefully that was easier to read than Investopedia. If the use of “margin” here confuses you, just map it to “percentage” in your head. (I do not recommend saying that out loud at corporate meetings.)

The last bullet above, r(n)−v(n)−f is very close to the colloquial usage of “profit” or net income. The only expenses left to take out are interest, taxes, and other investment-related expenses that you normally would not have to worry about (and probably have no control over.)

Brain Food 1: at your company, does payroll for full-stack engineers come under variable cost, or fixed cost? In some cases, companies add features to gain market share and sell more product units, and therefore each additional headcount could be considered a variable cost. In other cases, the product sells itself even if no new features are added. How is that accounted for on your company’s income statement?

Brain Food 2: how should one account for the share of time that the product group, in aggregate, spends on maintenance vs development?

Bonus: Thinking on the Margins

When thinking about growth and scale, it can often be helpful to think in terms of additional revenue and additional cost for each unit sold. We can use the following terms:

  • Marginal Revenue (MR): additional revenue from each additional unit sold. Normally, this would be p, but since p is not always fixed (e.g. bundled deals, volume discounts), marginal revenue is more precise.

This use of marginal is different from Gross Margins above. Gross Margins and Operating Margins are averages, and not incremental.

Whenever MR > MC, then we are making money on that additional unit sold. This brings me to one of my favorite diagrams from microeconomics:

Fig. 3: Marginal Cost, Marginal Revenue, and Price.

Tying this back to Brain Food 1: if we were to make product investment decisions solely on cost and revenue, we would compare the marginal cost of hiring those additional full-stack engineers, against the marginal revenues from acquiring additional market share.

Continue reading Part 2.

Engineering@Samsara (ex-Affirm) -