The Case for Owning Your Software

I run a surplus goods business. I've also spent the last two years building the internal software that runs it — a 30-module FastAPI/React platform that handles inventory, catalog publishing, margin reporting, and lifecycle email. No external SaaS product manages any of those workflows anymore. I own the stack.

That probably sounds like a lot of work. It used to be. Then agentic AI coding happened, and the cost curve broke.

This post is my attempt to articulate why I think "buy don't build" — the default wisdom for two decades of software-driven business — deserves a serious re-examination in 2026. Not as a universal prescription, but as a live question every operator should be sitting with.

The SaaS Sprawl Problem Is Real, and It's Getting Worse

The average SMB runs somewhere between 20 and 50 SaaS subscriptions. Each one was a rational decision in isolation — a tool that solved a specific pain, with a free trial and a monthly rate that felt like nothing. But the compound picture is ugly:

• Cost: $500–$5,000/month per meaningful tool, stacking up quietly until it's a real line item
• Data fragmentation: Your customer data lives in your CRM. Your revenue data lives in Stripe. Your ops data lives in your ERP. None of them talk cleanly. You're duct-taping Google Sheets exports between them.
• Vendor lock-in: The longer you run on a platform, the more of your process is encoded in its quirks. Migrating off becomes a project, then a risk, then something you keep deferring.
• Surface area for failure: Every vendor is an outage, a pricing change, a terms-of-service update, or an acquisition away from disrupting your operations

"Every tool you rent is a dependency you don't control. Dependencies are risk. Risk compounds."

I've lived all four of these. The breaking point for me was when a catalog management SaaS repriced mid-contract, gave us 60 days' notice, and our entire feed publishing process — built around their API — needed to be rebuilt regardless. That experience reframed how I think about operational software.

The AI-Native Build Economics Shift

Here's what changed: for most of the SaaS era, the "buy don't build" default was genuinely correct. Building internal software was expensive. You needed senior engineers, long timelines, and the operational discipline to maintain what you shipped. For 95% of businesses, that was out of reach.

Agentic coding has restructured that calculus in three ways:

Speed. A well-scoped internal tool that would have taken a mid-level engineer 6–8 weeks to build can now be prototyped in days and hardened into production-grade software in 2–3 weeks. I'm not talking about vibe-coded throwaway scripts — I mean tested, versioned, CI-deployed software with real documentation.

Cost. The labor cost of building drops dramatically when AI handles scaffolding, boilerplate, and the first 70% of implementation. What you're paying for is judgment, architecture, and the hardening pass — not hours of typing.

Maintainability. The objection "but who maintains it?" used to be devastating. It's weaker now. AI-assisted maintenance — adding features, fixing bugs, refactoring — follows the same curve. A well-architected self-owned tool is more maintainable in 2026 than it was in 2016, even with the same human team.

This doesn't mean build everything. It means the build option is on the table in a way it wasn't before, and your decision framework should reflect that.

The Sovereignty Argument

Beyond economics, there's a strategic case for ownership that I think gets underweighted.

When you own your operational software, you own the data model behind it. You define the schema, the relationships, the retention policy. Nobody else can deprecate an endpoint you depend on, or sunset the feature that your whole workflow rests on. You're not subject to another company's product roadmap.

More importantly, you can build exactly for your workflow — not a generalized workflow that your business has adapted itself to fit. The number of times I've watched a team contort their process to match what a SaaS product allows is striking. The product should serve the business, not the other way around.

Technical sovereignty also compounds. Once you've built a real data layer you own, every subsequent tool you build can draw on it cleanly. You're not re-integrating from scratch each time. The second internal tool is faster than the first. The third is faster still.

When to Still Buy

I'm not a build-everything absolutist. There are categories where buying remains the right call:

• Commodity infrastructure: Email delivery, DNS, cloud compute, payment processing. The build cost isn't justified when the SaaS equivalent is commoditized, reliable, and cheap.
• Regulatory complexity: Anything touching payroll, benefits, or legal compliance carries liability that bespoke software doesn't insulate you from. Use the regulated tool.
• Network-effect products: CRMs with deep partner integrations, marketplaces, communication tools where the value is in the network. You can't replicate that.
• Non-core workflows: If the process isn't core to your competitive differentiation, buying the generic solution is probably fine. Spend your build budget where it creates a moat.

The question I now ask is: Is this workflow core enough that owning the software gives us a durable advantage or meaningful cost reduction over a 3-year horizon? If yes, build. If no, buy. But the threshold for "yes" is lower than it used to be.

What "Technical Sovereignty" Actually Looks Like

In practice, the shift I'm advocating for doesn't mean rewriting your whole stack. It means:

1. Auditing your SaaS spend for workflows where a self-owned tool would be cheaper over 36 months and give you better data access
2. Starting with one tool — the one where vendor dependency feels most like risk, or where the workflow is most specific to how you operate
3. Building to a standard: CI/CD, semantic versioning, tests, documentation. Not a script. Software.
4. Treating the data layer as the asset — your schema, your history, your reporting surface. That's the compounding return.

This is the frame I bring to every engagement. Not "here's a tool," but "here's the capability your business should own, and here's what it would take to own it well."

The Optimist's Case

I want to be clear that I'm a techno-optimist about this. The story here isn't "SaaS bad, return to roots." It's "the technology curve has shifted, and rational operators should update their priors."

SaaS gave millions of businesses access to software capabilities they couldn't have built. That was a genuine unlock. Agentic AI is now giving those same businesses the ability to build capabilities that are precisely fit to their context — at a cost that competes with what they were renting.

That's not a threat to software. That's software getting better. The businesses that figure out how to translate AI-assisted engineering into owned operational infrastructure are going to have a structural cost and data advantage over those that keep renting.

The window to build that advantage is open. It won't be open forever — the same AI tools that make bespoke software economical for you are available to your competitors. The moat is in moving first and building well.

That's the case for owning your software.