Stop Renting Software You Could Own

Here's an uncomfortable question for your next executive meeting: why are you paying $50,000 a year to rent software that your team could now build in a fortnight?

I'm not talking about your core ERP or your CRM. I'm talking about the sprawling landscape of point solutions, workflow tools, and "productivity platforms" that have colonised your tech stack over the past decade. The ones that started at $500 a month and now cost $5,000. The ones where you use 20% of the features but pay for 100%. The ones that just sent you another email about "exciting AI enhancements" that will cost extra.

Something fundamental has shifted. And if your finance frameworks haven't caught up, you're haemorrhaging money while calling it "operational efficiency."

The Opex Comfort Blanket

Let's be honest about why SaaS became the default. It wasn't because subscription software was always the best solution. It was because Opex was easier to justify than Capex.

No large upfront investment. No capitalisation debates. No depreciation schedules. No awkward conversations with the board about multi-year payback periods. Just a predictable monthly line item that finance could model and procurement could negotiate.

The unstated assumption was that building software was expensive, slow, and risky (while buying it was cheap, fast, and safe). For most of the 2010s, that assumption held. If you wanted custom software, you needed a team of developers, months of requirements gathering, and a prayer that what got delivered would actually work.

So we rented. We rented project management. We rented document workflows. We rented customer feedback tools, scheduling systems, approval platforms, and analytics dashboards. We rented so much software that the average enterprise now runs over 300 SaaS applications.

And every single one of them is a landlord who can raise the rent.

The Hidden Cost of Perpetual Tenancy

The SaaS model has a dirty secret: you never stop paying. And the payments tend to go in one direction.

Consider the trajectory. Year one, you sign up for a tool that solves a genuine problem. Year two, they add features you didn't ask for and raise the price "to reflect enhanced value." Year three, they introduce tiers (and the feature you actually need is now in the "Enterprise" bracket). Year four, they're acquired by private equity, and suddenly there's a platform fee. Year five, you're locked in by workflow dependencies, data gravity, and the sheer pain of migration.

This is the Opex trap. What felt like flexibility became dependency. What looked like operational expenditure became permanent rent on capability you'll never own.

And it gets worse. Because SaaS vendors optimise for their business model, not yours, you inherit their priorities. You get features designed for their average customer, not your specific context. You get integration architectures that favour their ecosystem. You get roadmaps driven by what helps them upsell, not what helps you operate.

The integration tax alone is staggering. How many hours has your team spent building Zapier workflows, wrestling with APIs, and maintaining brittle connections between systems that were never designed to talk to each other? That's hidden Opex too (and it compounds every time you add another tool to the stack).

The Build Economics Have Flipped

Here's what changed: AI collapsed the cost of building custom software by an order of magnitude.

I'm not speculating. I've watched teams build functional internal tools in days that would have taken months two years ago. Not prototypes (working systems). Approval workflows. Customer portals. Reporting dashboards. Document processing pipelines. The kind of bespoke solutions that used to require a six-figure budget and a prayer.

The economics are almost absurd. Take a scheduling and resource allocation tool. A mid-market SaaS solution might cost $30,000–$50,000 per year. An internal team with AI assistance can now build a custom version (tailored exactly to your workflows, integrated with your existing systems, owned outright) in two to three weeks of effort. The ongoing cost? Hosting and maintenance, maybe a few thousand dollars annually.

Run that comparison over five years. The SaaS route: $150,000–$250,000, plus integration costs, plus the features you pay for but don't use, plus the price increases you can't control. The build route: perhaps $30,000–$50,000 all-in, and you own the asset.

This isn't true for everything. Complex platforms with network effects, regulatory compliance requirements, or genuine economies of scale still make sense to buy. But the threshold has moved dramatically. A huge swathe of point solutions that made sense to rent in 2020 now make sense to own in 2025.

The Accounting Framework Hasn't Caught Up

Here's the problem: most organisations' financial frameworks still assume the old economics.

Capex requires business cases, board approvals, multi-year projections, and capitalisation schedules. Opex requires a cost centre code and a signature. When the monthly SaaS invoice arrives, it flows through accounts payable without friction. When someone proposes building an equivalent tool, they face a gauntlet of governance designed for a different era.

The irony is acute. We've made it easier to commit to perpetual payments than to make one-time investments in owned assets. The approval process actively biases organisations toward the more expensive long-term option.

And then there's the accounting treatment question. When you build software with AI assistance, what have you actually created? If a small team produces a durable internal tool in two weeks, is that Capex or Opex? Can you capitalise the labour? What about the AI subscription costs that enabled the work? What's the useful life of software that can be modified and extended indefinitely?

These aren't hypothetical questions. They're hitting finance teams right now, and most don't have clear answers. The accounting standards were written for a world where software development meant large teams, long timelines, and distinct project phases. That's not this world.

From Renting Capability to Building It

This is really a question about what kind of organisation you want to be.

For the past fifteen years, the dominant strategy has been to outsource capability to vendors. Need a workflow? Buy a tool. Need analytics? Subscribe to a platform. Need automation? Implement someone else's solution. The implicit bet was that external specialists would always outperform internal generalists, and that the premium was worth paying for quality and speed.

That bet created a dependency model. Organisations became consumers of capability rather than builders of it. The internal muscles for creating solutions atrophied. The institutional knowledge of how things actually work migrated to vendor documentation and support tickets.

AI changes the equation. It's now possible to rebuild those internal muscles at dramatically lower cost. Not by hiring armies of developers, but by enabling the people who understand your business to create the tools your business needs. The product manager who knows exactly what the workflow should do. The operations lead who understands the edge cases. The analyst who's been manually producing that report for three years.

These people can now build. Not because they learned to code in the traditional sense, but because AI has made it possible to translate business intent into working software without the translation layer of a development team. The capability gap that justified outsourcing is closing.

A Framework for the New Economics

So what should executives actually do? Start by challenging three assumptions:

First, audit your SaaS sprawl with fresh eyes. For each subscription over $20,000 annually, ask: could we build a fit-for-purpose alternative in weeks rather than months? What's the five-year total cost of ownership comparison? What capability are we renting that we could own?

Second, update your approval frameworks. If your governance makes it easier to commit to $50,000 per year forever than to invest $50,000 once in an owned asset, your governance is broken. Create fast-track approval paths for internal build projects under a certain threshold. Treat them as experiments with option value, not capital projects requiring exhaustive justification.

Third, invest in internal capability. This doesn't mean hiring developers. It means enabling your existing people to build. Training. Tools. Time. Permission. The organisations that will thrive are the ones that treat "we could build that" as a realistic option rather than a fantasy.

The Strategic Question

Underneath the accounting debate is a strategic one: do you want to be an organisation that builds capability, or one that rents it?

There's no universally right answer. Some organisations should absolutely continue buying. They lack the internal talent, the appetite for ownership, or the strategic importance of custom solutions. For them, SaaS remains the sensible default.

But if you believe that operational capability is a source of competitive advantage (if you think the way you do things matters as much as what you do), then the calculus has changed. The premium for owning rather than renting just collapsed. The barriers to building just fell away.

Your Capex/Opex framework was built for a world where buying was fast and building was slow. That world is gone. The organisations that recognise this will redirect hundreds of thousands of dollars from perpetual rent into owned assets. The ones that don't will keep paying the landlord, wondering why their competitors seem to move faster on lower budgets.

The lease is up. Time to decide whether you're buying the house.