The compounding tax of renting your operational stack

The four-component bill

The rental tax has four components, and only one of them appears on the invoice.

1. The cash component. The literal invoice. Easy to see, easy to underestimate, and the smallest of the four in most cases.
2. The lock-in component. Every month you operate inside a vendor's interface is a month spent training your workflows to depend on shapes you do not control. The cost of this component is invisible until you try to leave, at which point it is suddenly the only number that matters.
3. The data-extraction component. The cost of getting your own state out of the system in a form that another system can use. CSV exports lie about this — they are usually the cheapest, lossiest, slowest path to extracting value, and the vendor knows.
4. The repricing component. The expected value of all future price changes the vendor will impose without asking. This is non-zero. It is, on a five-year horizon, often the largest component of the total.

The visible bill is forty pounds. The all-in cost is several multiples of that. The first time an operator runs the calculation honestly, the conclusion is usually uncomfortable.

The real curve, not the marketing curve

Vendors price for the rate of growth they expect from a typical customer, not the price you agreed to on day one. A representative arc: a workflow tool starts at twelve pounds per seat per month. Adoption grows. The team doubles. The vendor introduces a tiered structure where the features you actually use are now in the next tier up, at twenty-eight per seat. A new compliance feature, mandatory for your sector, requires the enterprise plan at sixty per seat. Three years from sign-up the per-seat price is five times the headline number, and the marginal value to the business has not changed.

This is not adversarial. It is the rational behaviour of a venture-funded vendor optimising for revenue per logo. The structural problem is that the customer's leverage decreases as the embedding deepens. The longer you stay, the harder you are to lose, and the more the price reflects that fact.

Owning the corresponding capability inverts the curve. The capital expense is one-time. The operating expense is a small fraction of the rented equivalent. The capability does not become more expensive as your usage grows. The leverage, in the limit, sits with you.

What the rental tax is actually buying

The honest case for renting is real and worth stating. You are buying convenience, hosted reliability, the vendor's investment in product polish, the integration ecosystem, and someone else's twenty-four-seven on-call rota. None of those are nothing. For some capabilities — transactional email deliverability, payments processing, frontier model inference — they are the right answer.

The dishonest case for renting is what happens when those advantages have already been amortised away. Once the team has standardised on a workflow, once the data shape has stabilised, once the integrations are written and the on-call rota is rarely needed — the vendor's marginal contribution is mostly hosting and a UI. Both of those are commodity work. You can buy commodity work for less than rental prices, or you can build a thin layer that does the same thing on infrastructure you control.

The signal that you have crossed from honest renting into rental-tax territory is usually one of three things: the vendor's roadmap stops adding things you care about, your data volume in their system stops growing, or the cost-per-active-user starts climbing without a corresponding capability increase. When one of those is true, the calculation has flipped.

The compounding cost of optionality lost

The largest component of the tax is the one operators never see: the optionality you are not exercising because the rented stack would not let you. Every time a workflow you would have liked to build dies because the integration is impossible, every time a dataset you would have liked to merge cannot be reached across vendor boundaries, every time you do not run an experiment because the cost of plumbing it would be three months of development against a third party's APIs — that is a real cost. It just does not appear on any invoice.

The teams that own the spine of their stack run experiments at a rate roughly an order of magnitude higher than teams that rent it. The cost of trying something new on a stack you control is the cost of a few hours of work. The cost of trying it on a rented stack is the cost of an integration plus the political capital to negotiate the data access. Compounded over a few years, that ratio is the difference between a business that visibly improves on its own infrastructure and one that visibly slows down inside its vendors.

What we replace, and what we do not

For our own operation, the replacement list is roughly: customer database, project state, document store, time-series telemetry, knowledge base and embeddings, workflow orchestration, internal dashboards, scheduling, file storage, link shortening, secret management. All on hardware we own, all open-source software, all readable in standard formats with backup and recovery procedures we wrote.

The deliberate non-replacement list is: transactional email delivery, payments processing, registrar-level DNS, frontier model inference for the tasks that genuinely need it, and the public CDN that serves anonymous traffic to the marketing surface. The principle is that we self-host the long-lived state of the business and rent only the edges where specialisation meaningfully compounds. Rent the edge, own the spine.

Running the calculation honestly

If you want to run the rental tax calculation on your own stack, the version we use is unsentimental:

• List every recurring software invoice your business pays.
• For each, write down what your business would actually lose if the vendor disappeared in ninety days.
• For each, write down the realistic cost of running the same capability in-house — capital, operating, and time. Be honest about the operator hours.
• For each, write down the realistic five-year price the vendor will charge if your usage doubles.

The first time we ran this on our own books, four of the eleven recurring vendors were obviously overdue for replacement. Two more were borderline. Five were correctly rented. The total annual saving was substantial, the recovery period on the in-house build was under a year on the obvious ones, and the optionality gain was the largest line item — except that, by definition, it does not appear in the calculation. Which is the whole point.

The takeaway

The rental economy is not a conspiracy. It is a perfectly rational market response to a generation of operators who valued convenience over leverage. The cost of that trade is now visible on five-year horizons, and it is large. The good news is that the tools to invert it have never been more available — open-source software is mature, Apple Silicon and similar hardware classes have made on-premise inference economic, and the protocol layer between systems is finally standardising.

If you have not run the calculation in the last twelve months, you are almost certainly paying the rental tax on at least one capability you should already own. The first piece of advice is also the cheapest: write down what you are actually paying for, and be honest about what you are getting in return.