“You will own it” is one of the easiest things a software shop can say, and one of the easiest to fake. Real ownership is specific. It is set up from the first day, not bolted on at the end, and it comes down to a handful of concrete things you either hold or you do not.
Most shops sell dependence. The relationship is designed so that leaving is painful, because a client who cannot leave is a client who keeps paying. We build the opposite way on purpose. Here is what that means, in plain terms.
The five things you should hold
When we say a client owns their software, we mean they hold all five of these, in accounts with their own name on them:
- The code. The full source, in a repository you control. Not a copy we email you at the end. The live thing, from the start.
- The hosting. The servers and services it runs on, billed to you, cancellable by you, movable by you.
- The domains. The web addresses your users type, registered to your account, not held on your behalf.
- The data. Everything the system stores, exportable on demand in a format you can actually use.
- The knowledge. Documentation of how it works and how to run it, plus training for your team, in plain language.
That last one is the one shops skip most often, because undocumented software is its own kind of lock-in. If only the original developer understands the system, you depend on that developer whether or not you hold the code. Knowledge transfer is not a nicety at the end of a project. It is part of what ownership means.
What lock-in really looks like
Vendor lock-in is rarely announced. It shows up as small, reasonable-sounding arrangements that add up to a cage. The code lives in the shop’s account “for convenience.” The hosting is on the shop’s plan “to keep things simple.” The domain was registered by the shop “so you didn’t have to.” Each one sounds helpful. Together they mean you cannot leave without permission.
The test is simple. Ask your current or prospective developer one question: if we parted ways tomorrow, on bad terms, what would I be able to keep running without you. If the honest answer is “not much,” you do not own your software. You are renting it, and the landlord writes your code.
Independence is a design decision
Ownership cannot be added at the end. It is a set of choices made at the beginning about where things live and whose name is on them. That is why we set up the accounts in your name on day one, commit the code to your repository from the first line, and document as we go rather than scrambling at handover.
Doing it this way is slightly less convenient for us and much better for you. It also keeps us honest. When a client can walk away at any time and keep everything running, we have to earn the next engagement with good work rather than hold it with a hostage. That is the relationship we want.
Ending well is the point
Our engagements end by design. That sounds strange for a business to say, so it is worth being clear. We finish the project, hand over the keys, train your people, and step back. If you want us again, you hire us again by choice. Not because your software stops working without us.
Software you own is software that outlives its makers. If we disappeared, your system would keep running, your data would still be yours, and any competent developer could pick up where we left off from the code and the docs. That is not a flaw in our business model. It is the whole point of it.
Written by
Miles Bassett
Founder and principal craftsman at Prairie Code. He writes and speaks on deliberate AI adoption for small businesses and institutions.