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.

Introduction

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
  • companies that are pre-IPO or just after IPO

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?
  • How do I explain cloud costs to executives on a different side of the business?
  • How do I work with Finance? They always want a forecast.
  • How can I provide predictability? I don’t have the answers!
  • My team wants to add a cache that will cost $XXm/year. Is that worth it?
  • Our company is about to IPO before we are profitable. Should I be concerned?
  • When can we turn a profit?

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.
  • Fixed costs stay constant no matter how many product units you sell. Examples include the cost of designing the product, the desk you use at work, and the lease on office space for engineering.

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,
  • p be the unit price,
  • revenue be defined as r(n)=n×p,
  • variable costs that went into producing those n units be denoted by v(n), and
  • fixed costs be denoted by f.

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
  • v(n) is also known as Cost of Goods Sold, or COGS
  • r(n)−v(n) is also known as Gross Profit. Correspondingly, [r(n)−v(n)]/r(n) is your Gross Margin; higher is better, and 75% is the benchmark for a good SaaS company.
  • r(n)−v(n)−f is also known as Operating Profit. Correspondingly, [r(n)−v(n)−f]/r(n) is your Operating Margin; higher is better. More on this later.

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.
  • Marginal Cost (MC): additional cost of producing that additional unit sold. This is a more precise way of talking about v(n), and takes into consideration both economies of scale and diminishing returns.

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@Modern Treasury (ex-Affirm, ex-Samsara) - jimjh.com

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store