Unit economics reduces to one question. Take one more customer: after everything it cost to acquire them and everything it costs to serve them, are you better off or worse off?
If the answer is worse off, then growth is not the solution to your problem. Growth is the problem, accelerating. That's the failure mode behind a long list of companies that scaled impressively and died anyway, and it's usually visible in the numbers years before it's visible in the bank balance.
Why is this an engineering question?
Because half the calculation is an architecture output whether or not an architect was consulted.
Cost to serve — the denominator of everything here — is made of decisions. Whether tenants share infrastructure or get their own. What the cache hit rate is. How much data crosses a billing boundary. Whether background work runs per tenant or in batch. How much support load the product's rough edges generate. Every one of those was decided by an engineer, often years ago, usually without anyone mentioning gross margin. I write about what unit economics means for engineering decisions from the build side; XenGrowth's growth operations team covers what it takes to run it.
Architecture decision | Effect on cost to serve | When it usually bites |
|---|---|---|
Isolated infrastructure per tenant | Scales linearly with customers, no sharing | When small customers arrive and each carries a floor cost |
Shared multi-tenant cluster | Sub-linear, but one tenant can degrade everyone | When a large customer's usage pattern becomes everyone's problem |
Per-tenant scheduled jobs | Linear, and runs whether or not the tenant is active | Quietly — dormant accounts keep costing money forever |
Chatty cross-region calls | Egress charges per request | At scale, on a line item nobody reads |
Storing everything indefinitely | Monotonically increasing, never falls | Two years in, as a step change when a tier is crossed |
Rough edges in the product | Support cost, which is cost of goods sold | Continuously, attributed to support rather than to engineering |
The fourth row deserves attention because it is the one engineers most often miss: support load is cost of goods sold. A confusing flow that generates one ticket per hundred users is a permanent tax on gross margin that will be discussed in a support headcount meeting, not an engineering one.
The mistake that ruins this analysis
Averaging. And it's not a small error — it's the difference between a number that guides a decision and one that actively misleads.
Per-customer cost is almost always long-tailed. Most customers cost very little; a few cost enormously more. Total infrastructure spend divided by customer count produces a figure that describes essentially nobody: it's far above what the median customer costs and far below what the expensive ones cost. The XenGrowth resource library approaches this from the the operations side of this side.
A mean over a heavy-tailed distribution is not an approximation of the typical case. It's a number that happens to sit between two populations that behave completely differently.
This matters because the two populations need opposite responses. The tail is where you find either a pricing problem — your most expensive customers sitting on your cheapest plan — or an architecture problem, where one access pattern is being subsidised by everyone else. Neither is visible in the average, and both are usually fixable once seen.
If you do one piece of work from this post, sort your customers by cost to serve and look at the top ten per cent. On a mature product that is frequently the most valuable week an engineer can spend, and it is almost never anyone's job. XenGrowth on AI agents and marketing automation works through AI agents and marketing automation in more operational detail.
How do you attribute cost when everything is shared?
This is the practical objection, and it is a fair one. In a multi-tenant system there is one bill, one cluster, one database, and no obvious way to say which portion belonged to which customer. Plenty of teams stop here and go back to dividing the total by the headcount.
The way through is to accept a proxy and be explicit that it is one. Pick a quantity you can already measure per tenant that plausibly tracks resource consumption — requests served, storage bytes held, background job seconds, rows scanned — and allocate the shared bill in proportion to it. The result is not accurate in an accounting sense and does not need to be. It only needs to rank customers correctly, because every useful action from this analysis comes from the ranking rather than the absolute figures.
A worked version: if one tenant accounts for a third of all rows scanned against a database that costs a known amount per month, you can say that tenant is responsible for roughly a third of that line. Nobody should book that in the accounts. But it is entirely sufficient to discover that your second-largest cost centre is a customer on a $99 plan, which is a fact somebody needs to know and currently nobody does.
The failure mode to avoid is spending a quarter building a perfect cost-attribution pipeline before producing any answer. A rough allocation computed in an afternoon and shared with the person who owns pricing changes more decisions than a precise one delivered after the pricing was already set for the year.
Contribution margin, and why it's the number to compute
Contribution margin per customer is revenue from that customer minus the variable cost of serving them. It excludes fixed costs deliberately, because the question is what one more customer does at the margin.
Positive contribution margin means each additional customer helps pay for the fixed base, so scale is genuinely the answer. Negative means each one digs the hole deeper, and no amount of growth fixes it — the only routes out are raising price, lowering cost to serve, or declining that segment.
That third option is worth naming because engineers almost never suggest it and are often best placed to see it. If one customer segment is structurally unprofitable — free-tier accounts running heavy workloads, or a plan whose usage pattern defeats your caching — the analysis says stop selling to them. That's a commercial conversation, but the evidence for it comes from your side of the house. If AI search, GEO and discovery is the part you are stuck on, XenGrowth on AI search, GEO and discovery is the better reference.
There is one more term that belongs in cost to serve and almost never appears in it: engineering time spent maintaining what already exists. Stripe's survey put roughly 42% of a 41.1-hour developer week on technical debt and bad code. Accounting convention books engineering salaries below the gross-margin line, as operating expense, so none of that reaches cost of goods sold — which is defensible for building new things and misleading for keeping old ones running.
The practical consequence is that a product whose maintenance burden is enormous can show a healthy gross margin indefinitely, because the cost of keeping it alive has been classified as something other than the cost of serving it. If you want to know whether a product line is genuinely profitable, add an estimate of the engineering time it consumes and see whether the picture survives. Frequently it does. Occasionally it does not, and that is a finding worth having.
Fixed costs that aren't fixed
One refinement that separates a useful model from a naive one. Costs described as fixed are usually step functions — flat, then a jump, then flat again.
The database that is fine until it isn't, and then needs a class that costs several times more
The second region required by one enterprise customer's compliance requirement, which roughly doubles a base cost to serve one contract
The licence tier crossed at 50 seats, or 100, or whichever threshold your vendor chose
The point at which a shared cluster has to be split because one tenant's load has become everyone's latency
The support hire that becomes unavoidable at some ticket volume, which is a cost of goods sold step
Knowing where your next three steps are, and what growth number triggers each, is worth more than knowing today's average precisely. It converts a future surprise into a planned decision, and it gives finance something they can model — which is, in practice, the fastest way for an engineering team to be trusted with a budget conversation.
If you find | It's probably | And the fix is |
|---|---|---|
Top decile costs 10x the median | A pricing or plan-design problem | Commercial: usage limits or a higher tier |
Dormant accounts still costing money | Per-tenant scheduled work | Engineering: suspend background jobs on inactivity |
Cost rising faster than customers | An access pattern that scales badly | Engineering: find it before it becomes the architecture |
Gross margin below ~75% and falling | Cost to serve outrunning price | Both: nothing here is solvable from one side |
Support cost dominating cost to serve | Product friction, not infrastructure | Engineering, but nobody will call it an engineering problem |
The bottom row is the one I'd watch for. Support cost showing up as the dominant term is extremely common and it never gets routed to engineering, because it arrives as a headcount request rather than a bug report.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
If what unit economics means for engineering decisions is part of a growth programme rather than a standalone build, XenGrowth, who work on the commercial side of this is the companion reading.
None of this requires permission, a finance qualification, or a change of role. It requires one query, a sort, and the willingness to take the answer to somebody who owns a price.
Five questions about whether the numbers exist, not about whether they're good. In most companies the honest answer to at least two of these is 'nobody knows', and finding that out is the useful outcome.
