A founder we talked to last year had a clean little product running on a no-code platform. Forty paying customers, growing. Then the platform changed its pricing tier and his monthly bill went from manageable to roughly four times what it was, overnight. He had two options. Pay it, or rebuild the whole thing on something he controlled. Rebuilding meant three months of work he didn't have and money he didn't want to spend. He paid. He is still paying.
That is the real shape of the ownership question. Not a philosophy debate about open standards. A bill that lands one morning and you have no room to argue with it.
So when people say "own your software," it is worth asking what that ownership actually buys, and what it costs to hold.
Ownership is a position, not a checkbox
You do not own or not-own your software in some binary way. You own it at certain layers and rent it at others, and the question that matters is whether you control the layers that would hurt to lose.
A company can run on AWS, charge through Stripe, and host its code on GitHub, and still be in a strong position. Those are infrastructure and tooling. If AWS doubled its prices you would grumble, maybe move some workloads, but your product would not stop being yours. The logic, the data model, the thing that makes your product specifically yours, lives in code you wrote and can move.
Compare that to the founder above. His business logic lived inside someone else's tool. The rules that ran his product were configuration in a system he did not control. When the terms changed, he had nothing to take with him. That is the difference. Not whether you use vendors, everyone uses vendors, but whether the vendor sits on a layer you could survive losing.
The test we use on every architecture call is blunt. If this vendor disappeared on Monday, what breaks, and could we rebuild it without their cooperation? If the answer is "everything breaks and no," that is a layer you do not actually own, and you should know that going in.
The reasons this got more urgent
A few years ago you could be relaxed about this. The tools felt permanent. Three things changed that.
The first is AI. Most products now have some AI feature wired into them, and most of those features call a single model provider's API. That is fine until the provider changes the model behind the endpoint, deprecates the version you tuned your prompts against, or adjusts pricing per token. We have watched teams discover that a model update silently changed their output quality and there was nothing to roll back to, because they never owned the model or the version. Owning your AI does not mean training your own model from scratch, almost nobody should. It means controlling the pipeline around it: your prompts versioned, your data flows yours, and ideally the ability to swap providers without rewriting half your app.
The second is data residency. Regulations in India, Europe, and a growing list of other places now require you to know exactly where your data physically sits and who can touch it. A lot of multi-tenant SaaS products genuinely cannot answer that question for you, because your data is mixed into their system in ways they have abstracted away. If a regulator or a serious enterprise customer asks where the data lives and your honest answer is "somewhere inside a vendor I can't audit," you have a problem that is no longer technical. It is legal, and it can lose you the deal.
The third is consolidation. The developer tools market has been getting acquired and shut down at a pace that should make anyone cautious. A tool that felt like infrastructure five years ago is now a feature inside a larger company, or sunset entirely with twelve months notice. Every dependency you take on is a bet that the company behind it will still care about your use case in three years. Some of those bets are safe. Many are not, and people make them without noticing they are bets at all.
What we actually do about it
When we start an engagement, before any code, we try to answer one question with the client: what do you need to own, specifically, to be safe? The answer is never "everything." It is usually a short list, and it shapes the whole build.
In practice the projects that age well tend to share a few traits. The data schema is something the client's own team understands and can export tomorrow, not a black box. The application logic is separated cleanly from the infrastructure it happens to run on, so moving from one cloud to another is a weekend of pain instead of a rewrite. File formats and integrations lean on open standards where a standard exists, because proprietary formats are how vendors keep you. And the deployment can, if it ever has to, be self-hosted or moved, even if today it runs on a managed service for convenience.
None of that is heroic engineering. There is no clever framework involved. It is mostly a series of small, boring decisions made early, when changing them is cheap, instead of late, when changing them costs a rebuild. The teams that end up trapped rarely made one big mistake. They made fifty small convenient choices, each reasonable on its own, that added up to a product they could not move.
Where the advice stops being true
Here is the part the ownership crowd tends to skip. Sovereignty has a running cost, and for a lot of teams it is not worth paying.
Managed services exist for a reason. They take operational work off your plate, monitoring, patching, scaling, the unglamorous stuff that someone has to do at three in the morning when it breaks. The moment you own a layer, you own that work too. A two-person startup that self-hosts its database to feel sovereign has not gained independence. It has gained a second job, and probably a worse uptime record than the managed option it replaced.
For an early team, a well-chosen SaaS is almost always the right call. The goal is not to own everything. It is to own the few things that actually give you an edge, your data, your core logic, your customer relationships, and to rent the rest with your eyes open, knowing the exit cost before you sign up. You should be able to say, for every important dependency, what it would take to leave. If you cannot answer that, you do not have a sovereignty problem yet, you have an awareness problem.
That line, between what to own and what to rent, sits in a different place for every company. A regulated fintech draws it far more conservatively than a content startup. A team of four draws it differently than a team of forty. There is no universal answer, and anyone selling you one is selling you something.
What does not change is that the line should be a decision, not an accident. Most teams never decide. They accumulate dependencies until one of them changes the terms, and then they find out, the expensive way, which layer they should have owned all along. The founder paying four times his old bill knows exactly which layer that was now. He just knows it a year too late.
If you are making those calls right now and want a second opinion on where your line should sit, that is a conversation we are happy to have.