Stop renting AI: the case for bringing key software in-house

Walk through your software spend line by line and a pattern appears: over the last two years, a second SaaS stack has quietly grown on top of the first one. AI writing tools, AI meeting notetakers, AI report generators, AI-enhanced versions of things you already pay for — each $20 to $99 per seat per month, each adopted by somebody for a reason that made sense at the time.

Individually, they're rounding errors. Together, they're a lease — and what you're leasing is your own company's future capability.

Renting is how everyone starts. It's just a bad place to stop.

To be clear: renting AI is the right first move. Subscriptions are how you learn what's useful without betting real money. The problem isn't the renting — it's that most companies never graduate from it. Three years in, they have thirty subscriptions, no inventory of them, and workflows that break whenever a vendor changes a feature, triples a price, or gets acquired and shut down.

Here's the test we use with clients — we call it the walk-away test: if your most critical AI vendor tripled its prices tomorrow, could you leave?

• Do you know every workflow that depends on it?
• Is your data exportable — and have you ever actually tried?
• Are the prompts, configurations, and automations documented anywhere outside the tool itself?
• Are the accounts even owned by the company, or by employees personally?

If those answers make you wince, the subscriptions aren't tools. They're liabilities with good UX.

What "owning" actually means

Owning AI capability does not mean training your own model or hiring machine-learning engineers. For a mid-market company, ownership means five concrete things:

1. The accounts are yours. Every business-relevant AI account lives under company ownership, not personal emails. (This one costs an hour and removes your most embarrassing risk. Do it this week.)
2. The data is yours. You know where it lives, you can export it, and nothing sensitive flows anywhere your usage policy doesn't allow.
3. The workflows are documented. The process exists on paper, not just in the muscle memory of whoever built it.
4. The logic is portable. Prompts, templates, and automations are stored in your own repository, so switching vendors is a migration, not a rebuild.
5. Some software is simply yours. And this is the part that changed recently.

The build-vs-buy math has changed

The dirty secret of 2026: an enormous amount of what mid-market companies rent is now cheap to build. Internal tools — the intake form wired to your CRM, the report generator, the quote assembler, the document pipeline — used to require a dev team and a six-month roadmap. With modern AI-assisted development, a senior builder ships them in weeks, and they run for the cost of hosting.

The rule of thumb we use:

• Rent what's genuinely hard and generic: the frontier models, transcription, infrastructure.
• Own what encodes your business: workflows, prompts, integrations, and any internal tool where a vendor is charging you rent to access your own process.
• Never rent what's one price hike away from hostage-taking: anything a vendor can't be swapped out of within a quarter.

The CFO version: renting turns capability into perpetual operating expense with escalation risk you don't control. Owning turns a one-time build into an asset that compounds — and every workflow you own is one your competitors have to build from scratch.

Where to start

Not with a purchase and not with a build. Start with an inventory: one page listing every AI tool in the company, who uses it, what it costs, and what breaks if it disappears. Most leadership teams have never seen this list, and most are shocked by it.

Then rank: which three dependencies fail the walk-away test hardest? That's your ownership roadmap, in order.

---

This is the "Own" step of the Carbon Copy Method — and it's why the company is named what it's named: the deliverable is a copy of the capability, inside your company. The AI Opportunity Audit includes the full inventory, the dependency map, and build-vs-buy guidance for everything on it.