Stop renting your tools: the case for replacing the software you pay for with software you own
Look at your company card statement and read it as an engineer instead of a customer. Every subscription line is a dependency with a price that compounds: seats grow, tiers ratchet, the annual increase email arrives whether or not the product improved. You'd never accept a library that raised its price 8% a year and could delete itself on a missed invoice, yet half the software running your business works exactly like that.
Most professions have no move against this. A dentist can't build her own scheduling system; she pays whatever the vendor decides forever. You can. Programmers are the one profession that can look at a bill and convert it into an asset. We just spent a decade being talked out of it.
The build-versus-buy math quietly flipped
The standard advice, "never build what you can buy," was calibrated for a world where building meant months of an engineer's time against a $29 subscription. That was usually right, and I've made the extended version of that argument myself in the total cost of "we will just use X": the sticker price understates the cost of buying, too.
Agentic development broke the calibration. Work I'd have scheduled across a quarter now fans out to AI agents in parallel branches while I review results and reject the misses. The implementation cost of a focused internal tool dropped by an order of magnitude; the judgment cost stayed flat. When the denominator collapses like that, conclusions you've cached for years deserve a rerun.
I reran mine. One person plus agents replaced my analytics vendor, my uptime monitor, my BI dashboard, my report emails, and my cron monitoring with buildless services and one SQLite file on a VPS. The full account, including what it cost me, is in Replacing the SaaS bill. This post is the argument that piece is evidence for.
A bill dies; an asset compounds
Rent is pure expense. The day you stop paying, you're left holding nothing but an export file in a format designed to discourage leaving.
Owned software behaves like the opposite kind of line item. It's proprietary IP: it appears on the asset side, it can be licensed, it survives vendor pivots, and it can be assigned to a holding entity and sit above your operating businesses the way I described in my holdco post. When you sell a product, tooling you own transfers with it. Tooling you rent transfers as a liability the buyer renegotiates.
There's a compounding effect that never shows up in a build-versus-buy spreadsheet. Every owned tool teaches you your own system. My analytics schema taught me things about my traffic that no vendor dashboard surfaced, because vendors build for the median customer and you are not the median customer. The tool fits your workflow instead of the workflow bending to the tool, and each replacement makes the next one cheaper because the data plane and the deploy path already exist.
You own the pager now
Here's the discipline half, because the manifesto is dishonest without it.
When you rent, the vendor carries backups, uptime, security patches, and 3 a.m. failures. When you own, all of that lands on you, and it doesn't care that you're busy. My rule: an owned tool exists only if its backup is replicated, its restore is rehearsed, and its scheduled jobs alert on silence, not just on errors. A backup you've never restored is a rumor. An internal tool nobody operates is a slow-motion outage with your name on it, and I've written about what it takes for an internal tool to survive.
That discipline is the real price of ownership, and it's why this argument is aimed at programmers specifically. We're the profession for whom that price is payable. It still has to be paid.
What I refuse to self-build
Conviction without a stop list is how engineers end up maintaining a homemade payments system, so here's mine.
- Payments. Card handling, PCI scope, chargebacks, fraud. Stripe's fee is one of the best deals in software. I integrate it; I will never rebuild it.
- Email deliverability at scale. Reputation management with inbox providers is a full-time negotiation, and self-hosted SMTP loses it. Transactional email stays bought.
- Anything compliance-heavy. HIPAA, SOC 2 evidence, payroll, tax filing. The product is the audit trail and the liability transfer, not the CRUD around it.
- Primary identity for other people's money or data, unless auth is genuinely your competence. The failure mode is not an outage; it's a breach.
The pattern: buy where the vendor absorbs a risk you can't, build where the vendor is charging rent on a cron job, a dashboard, or a workflow you understand better than they do. Most of the SaaS market lives in that second category and would prefer you didn't notice.
Takeaways
- Read every subscription as a dependency with a compounding price, not a convenience.
- Rerun your cached build-versus-buy conclusions; agentic development changed the denominator.
- Owned tools are IP. Park them in the entity you want owning assets, not in the operating company taking risks.
- Ownership means the pager, the backups, and the rehearsed restore. No operator, no build.
- Keep payments, deliverability, and compliance bought. Convert the rest deliberately, one bill at a time.
Work with Kleto
I am James Cowan, a product engineer and the founder of Kleto. Kleto is a product engineering agency that ships production software from strategy through handoff. Converting rented tools into owned, operable systems is exactly the kind of work we take on with founders and small teams. If that matches your stack, contact Kleto and we will scope a sensible first step.