This is usually pitched as a loyalty exercise — care about the business, be a team player. That framing is why engineers ignore it, and they're right to.
Here's the practical version instead. The revenue model determines which technical tradeoffs are correct. Not which ones are politically easier — which ones are actually right. Two engineers can make opposite calls on the same question and both be correct, because they're serving different revenue models, and neither will be able to explain why to the other.
The same feature, four different correct answers
Take a concrete case: a reporting dashboard that runs an expensive query. You could cache aggressively, serve slightly stale data, and cut compute cost substantially. Or you could compute on demand, keep it exact, and pay for it. There is a whole operational layer above every engineer should know how their company makes money that XenGrowth's growth operations team documents.
There is no context-free answer. There are four, and which one applies is a business fact you may never have been told.
Revenue model | How usage relates to revenue | So the right call is |
|---|---|---|
Per-seat SaaS | Usage is free to the customer, pure cost to you | Cache hard. Every query you avoid is margin you keep |
Usage-based / metered | Usage IS the revenue | Careful — efficiency lowers your own invoice. Sell it as retention, not margin |
Advertising | Engagement is revenue; latency reduces it | Compute on demand if staleness costs a session. Speed is revenue |
Transaction fee / marketplace | Revenue only when a transaction completes | Optimise the transaction path ruthlessly; the dashboard barely matters |
Enterprise licence | Fixed fee, renewal is the event | Optimise for what the renewal conversation is about, usually reliability |
The second row is the one that surprises people, and it's worth sitting with. Under metered pricing, making the query cheaper reduces what you bill. An engineer who ships a large efficiency win has, in strict revenue terms, cut the company's income.
That doesn't make the work wrong. It makes the argument for it completely different — it's a retention and competitive-position argument, not a margin one. Present it as margin and someone in finance will correctly point out you've reduced revenue.
You cannot construct that argument without knowing the pricing model. And nobody will tell you, because to them it's ambient — the sort of thing everyone obviously knows.
Where engineering actually touches the P&L
One line, mostly: cost of goods sold. For a software business that's hosting, third-party APIs, data egress, and a share of support — the direct cost of serving a customer. Revenue minus cost of goods sold is gross profit, and gross profit over revenue is gross margin. If the operations side of this is the part you are stuck on, The XenGrowth resource library is the better reference.
Software businesses are generally expected to hold gross margin above roughly 75%. That expectation is the entire reason software is valued the way it is: a business that keeps 80 cents of every marginal dollar can grow into profitability in a way that one keeping 20 cannot.
Which means per-customer infrastructure cost is not a housekeeping concern. It's the input to the metric that determines what the company is worth, and it is very nearly the only line on the P&L that an engineer can move without anyone else's cooperation. Sales cannot fix your egress bill. You can. XenGrowth on AI agents and marketing automation approaches this from the AI agents and marketing automation side.
The mistake this prevents most often
It is not building the wrong thing. It is optimising the right thing in the wrong direction, confidently, for months, with nobody noticing because the work is genuinely good.
A team on a per-seat product spends a quarter making the platform handle ten times the request volume per customer. Excellent engineering, and under per-seat pricing that additional usage produces no additional revenue at all — it is pure cost of goods sold. The same quarter spent halving cost per seat would have moved gross margin. Both are performance work; one improves the business and one degrades it, and the difference is invisible from inside the codebase.
The inverse happens just as often. A team on usage-based pricing optimises away a large chunk of billable compute and presents it as a cost saving, having reduced revenue by more than it saved. The work may still be correct — a cheaper product is more competitive and customers stay longer — but the case for it was never a margin case, and making it as one invites a finance team to look closely and conclude the engineers do not understand the business. Which, in that specific instance, is true.
Neither failure is detectable with technical review. Both are obvious the moment someone asks what happens to revenue when usage goes up, which is a question with a one-sentence answer that almost nobody thinks to ask.
What reliability is actually worth
The other place the revenue model changes the answer, and where the change is largest.
In a transaction-fee business, an outage has an arithmetic cost: transactions that would have completed, times the fee. You can compute it, and once you can compute it, an argument for redundancy stops being a preference and becomes a comparison of two numbers. It also tells you something more useful — that reliability during peak hours is worth far more than reliability at 4am, so uniform uptime targets are a misallocation.
In an annual enterprise licence, a two-hour outage costs nothing this month. It may cost the entire contract at renewal, eleven months later. That's a completely different shape of risk — no immediate signal, one enormous discrete event — and it argues for spending on the things that get remembered at renewal rather than on aggregate availability. XenGrowth on AI search, GEO and discovery covers the AI search, GEO and discovery side of this.
Transaction fee: outage cost is computable per minute, and it varies enormously by time of day. Spend on peak resilience
Advertising: latency has a measurable conversion effect, so performance work has a revenue number attached and should be argued that way
Per-seat SaaS: an outage costs goodwill now and churn later; the link is real but lagged and hard to attribute
Enterprise licence: cost concentrates at renewal, so what matters is which incidents the buyer remembers, not the average
Usage-based: an outage directly reduces billable usage, which is the cleanest and most immediate of all — you can read it off the invoice
There is a version of this that applies inside companies with no external revenue at all — internal platform teams, public sector, non-profits. The model is different but the reasoning is identical: something is being traded for the resources you consume, whether that is another team's budget, a grant, or a service level someone has promised elsewhere. The question 'what does an hour of my team's output buy, and for whom' has an answer in every organisation, and the engineers who know it are consistently the ones whose proposals get funded.
How do you actually find this out?
It takes an afternoon, and nobody will think the questions are strange — most people are pleased to be asked about their own area.
What exactly is billed, to whom, and how often? Per seat, per usage unit, per transaction, flat fee, or some combination. Combinations are common and the mix matters more than the headline model
What does it cost to serve one customer for a month? If nobody knows, that is itself the finding, and working it out is a genuinely valuable piece of work nobody has done
What is gross margin, and which way has it moved over the last year? Falling gross margin in a growing company usually means cost per customer is rising, which is an engineering problem being recorded as a finance number
What actually causes customers to leave? Ask someone in support or customer success rather than reading a dashboard. The answer is often something small and fixable that nobody escalated
What has to be true for the company to be fine in eighteen months? This is the question that tells you which of your worries are the real ones
Ask a salesperson the fourth one and you'll learn more in twenty minutes than from a quarter of dashboards. They lose deals for specific, repeated reasons and they can list them.
Instead of saying | Say | Why it works |
|---|---|---|
"We should reduce our AWS bill" | "This is two points of gross margin" | Names a line the CFO already watches weekly |
"We need better uptime" | "An hour of peak downtime is roughly X in fees" | Converts a preference into a comparison |
"This needs refactoring" | "This is why the last three estimates doubled" | Ties the cost to a pattern they have already noticed |
"The API is slow" | "Latency here maps to the drop-off in step three" | Attaches the work to a number someone owns |
"We have technical debt" | "We spend about two days a week on it" | Roughly the Stripe finding, in local units |
None of these is a trick. They are the same claims, stated in the units the decision is actually made in — and the reason they work is that most engineering proposals lose not because they're weak but because they arrive in a unit nobody else in the room can compare against anything.
The version of this I'd resist is the one where understanding the business means agreeing with every commercial decision. It doesn't. It means being able to disagree in terms that can actually be answered — which is a stronger position than either enthusiasm or cynicism, and considerably rarer than both.
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
Working on every engineer should know how their company makes money inside a commercial team? XenGrowth's operator guides publishes operator guides on the revenue side of this work.
