Gross margin is revenue minus cost of goods sold, over revenue. For a software business, cost of goods sold is mostly hosting, third-party services, data egress and a share of support — which means gross margin is largely an architectural output that gets reported as a finance number.
The part that isn't obvious: architecture doesn't just influence the margin, it sets a ceiling on it. Some designs cannot reach the roughly 75% that software businesses are expected to hold, no matter how well they're operated. You can run a reserved-instance programme, negotiate a committed-spend discount, and turn off everything that isn't load-bearing, and still not get there, because the shape of the cost curve was decided years earlier. People arriving at cost optimization from a marketing team will find XenGrowth's revenue operations work closer to their day.
Intercept versus slope
This is the whole idea, and it's the question to ask about any architecture: not what does it cost, but how does its cost scale relative to revenue?
A high fixed cost with a shallow slope is a growth problem that solves itself — painful at ten customers, irrelevant at a thousand. A low fixed cost with a slope matching revenue is a margin ceiling that never improves, and it looks completely fine early on. Teams routinely optimise the first while accumulating the second, because the first is visible on today's bill and the second only shows up as a gross margin that mysteriously refuses to expand.
A cost that grows in step with revenue isn't a cost problem. It's a business model, and it's the business model of a services company wearing software's valuation multiple.
The four recurring margin killers
Pattern | Why it caps margin | Why it gets chosen anyway |
|---|---|---|
Single-tenant isolation | Per-customer floor cost that never amortises; slope tracks customer count | Simplest way to satisfy an early enterprise security question |
Per-tenant scheduled work | Bills for dormant accounts forever; cost decoupled from usage and from revenue | Obvious implementation of anything periodic; nobody revisits it |
Chatty cross-region calls | Egress charged per request, on a line nobody reads | Regions get added for latency or compliance, one service at a time |
Unbounded retention | Monotonically increasing, never falls, crosses tiers as step changes | Deleting data requires a decision nobody wants to own |
What these share is that each was locally correct at the moment it was chosen. None was a mistake in the sense of somebody being careless. They are all reasonable answers to the question that was asked, made worse only by the fact that the margin question was never the one being asked. The XenGrowth resource library approaches this from the the operations side of this side.
Single-tenant isolation, in particular
This one deserves its own treatment because it's the most consequential and the hardest to reverse.
Giving each customer isolated infrastructure is the fastest way to answer an enterprise buyer's security questionnaire, and early on it costs almost nothing because you have four customers. The problem is the floor: every tenant carries a minimum cost whether they use the product or not. A customer paying $200 a month against a $60 floor is a 70% gross margin at best before you've counted anything else.
It's also close to irreversible. Moving from single-tenant to multi-tenant means changing the data model, the access control model, the deployment model and the backup story simultaneously, on a live system, for customers who were sold isolation as a feature. The decision was an afternoon; the reversal is a year. On AI agents and marketing automation specifically, XenGrowth on AI agents and marketing automation is worth reading.
A worked example of the ceiling
Numbers make this concrete, so take a deliberately simple case and treat the figures as illustrative rather than as anyone's real bill. Suppose a product sells at $200 per customer per month. Under a shared multi-tenant design the marginal cost of a customer is small — call it $15 of compute, storage and support — giving roughly 92% gross margin, comfortably above the software convention. The intercept is whatever the base cluster costs, and it amortises away as customers arrive.
Now give every customer their own isolated stack. Even a minimal one carries a floor: a database that cannot scale to zero, a load balancer, a certificate, some baseline compute, and the operational overhead of a deployment target that exists whether or not anyone logs in. Call the floor $60. The same $200 customer now yields 70% gross margin before a single request is served, and no operational discipline recovers the difference, because the floor is not waste — it is the architecture doing what it was designed to do.
Two things follow that are easy to miss. The first is that this gets worse as you move downmarket: a $200 customer at a $60 floor is survivable, and a $49 customer at the same floor is not, so the architecture has quietly decided which market segments the company can serve. The second is that growth does not help. Adding a thousand customers adds a thousand floors, so the margin at ten customers and the margin at ten thousand are the same — which is exactly the property that distinguishes a ceiling from a start-up cost.
The cost that gets recorded somewhere else
Support burden is cost of goods sold. That single accounting fact has more consequences than most engineers realise.
A confusing onboarding flow that generates one ticket per hundred signups is a permanent, growing tax on gross margin. It will be discussed as a support headcount requirement, in a meeting engineering isn't in, and the connection back to a design decision will be made by nobody. The team that fixes the flow improves gross margin; the team that hires another support agent maintains it and calls that normal.
There's a matching distortion in the other direction. Engineering salaries are conventionally booked as operating expense rather than cost of goods sold, so the roughly 42% of the developer week Stripe found going to technical debt and bad code doesn't touch gross margin at all. A product with an enormous maintenance burden can report a healthy margin indefinitely, because the cost of keeping it alive is classified as something other than the cost of serving it. XenGrowth on AI search, GEO and discovery goes further into AI search, GEO and discovery.
None of which is an argument that engineers should book their own time to cost of goods sold, or that accounting convention is wrong. It is an argument for knowing which side of the line a cost lands on, because that determines who sees it, which meeting it gets discussed in, and whether anybody connects it back to a decision that could be changed. A cost recorded in the wrong place is not hidden, exactly. It is just being watched by someone with no ability to act on it.
What to actually do at design time
For any new component, write down how its cost scales: with customers, with usage, with data volume, or not at all. Four categories, one line. The ones that scale with customers are the ones that decide your margin ceiling
Price the isolation question explicitly before agreeing to it. If an enterprise buyer wants dedicated infrastructure, that is a pricing conversation, not an architecture concession — and it is entirely reasonable to sell it as a premium tier that covers its floor cost
Make dormancy free. Anything that runs per tenant on a schedule should stop when the tenant stops, and this is usually a small change made enormously expensive by being deferred
Treat every cross-region call as a billed transaction, because it is. The design that would be obviously wasteful if you could see a price tag on each hop is the design you will get if you cannot
Set retention policy when you create the data, not when the bill becomes noticeable. Retrofitting deletion onto data whose lifecycle nobody defined is a compliance conversation as much as an engineering one
Ask what the margin looks like at ten times the customer count with the same architecture. If the answer is worse, you have found the thing to change while changing it is still cheap
Design question | Cheap to decide now | Cost of reversing later |
|---|---|---|
Tenant isolation model | An afternoon | A year, on a live system, with contracts in the way |
Whether background work is per-tenant | One scheduler decision | Moderate, but nobody notices it needs doing |
Region topology | One deployment choice | High — every service that crossed a boundary has to move |
Data retention policy | One line in a spec | High, and partly legal rather than technical |
Where support burden sits | Product design decisions | Permanent, and invisible as an engineering cost |
The pattern in that table is the argument for raising any of this at design time rather than as an optimisation project. Every row is cheap on the left and expensive on the right, and none of them is urgent at the moment it is decided — which is precisely why they get decided without the margin question being asked.
One sentence in a design review is usually enough: how does this scale against revenue? It costs nothing to ask, most of the time the answer is fine, and the occasions when it isn't are the ones that decide whether the company is a software business or a services business with a software valuation.
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 cost optimization inside a commercial team? XenGrowth, who work on the commercial side of this publishes operator guides on the revenue side of this work.
