Do you own the custom software you pay someone to build?
Yes. When you pay to have custom software built, you own it outright - the code, the documentation, and the keys. That's the whole point, and it's the clearest line between owning a tool and renting one.
The honest answer is also worth saying plainly: not every build delivers ownership by default. So here's what real ownership looks like, and what to check before you sign anything.
What you actually get when you own it
Ownership isn't a feeling - it's a short, concrete list of things that should be in your hands when the work is done:
- The code. The full source, in a repository you control. Not a hosted copy you can only see inside someone else's product.
- The documentation. How it's built, how it runs, and how to change it - written down, not locked in one person's head.
- The keys. The accounts, credentials, and deployment access. The tool runs on your infrastructure, under your control.
If you have those three, you own the tool. You can run it, move it, extend it, or hand it to another developer - without asking anyone's permission.
Why the stack matters as much as the code
Owning code that nobody else can read isn't ownership - it's a different kind of lock-in. That's why I build on a standard, well-documented stack: common languages and frameworks that any competent developer can pick up.
The test is simple. If I disappeared tomorrow, could you hire someone to maintain your tool without rewriting it? With a standard stack, the answer is yes. With a bespoke, exotic, or deliberately obscure setup, the answer is often no - and that's where people get trapped.
So ownership has two parts: you hold the code, and the code is built so someone other than its author can work on it.
How this contrasts with SaaS - where you own nothing
With a SaaS subscription, you own nothing. You rent access. That's not a criticism of SaaS - for commodity needs like email, accounting, or payments, renting is the correct, cheap choice. But it's worth being clear about what the monthly fee buys, and what it doesn't.
- Your data lives in their system, on their terms. You can usually export it, but you don't hold the tool that gives it meaning.
- You pay forever. Per seat, per month, for as long as you use it. The price can rise, and you absorb it.
- You don't control the roadmap. If the vendor deprecates the feature you depend on, raises prices, or gets acquired, that's your problem to absorb, not theirs to fix.
When you stop paying, you walk away with nothing. When you own a custom tool, you stop paying and you still have the tool.
What "no lock-in" really means
Lock-in is anything that makes leaving expensive on purpose. Owned, standard-stack software is the opposite of that by design:
- No per-seat pricing and no monthly SaaS fee - it's a one-time build, then it's yours.
- No retainer required to keep it running.
- No single vendor you're forced to stay with, because any developer can maintain or extend it.
You keep a direct line to me for changes if you want it. But the point is that you're never stuck with me. Ownership only counts if you're free to leave.
What to check before you commission a build
Ask three questions before any custom build starts:
- Where does the code live, and is the repository mine?
- Is it built on a standard stack any developer can maintain?
- Do I get the documentation and the keys at handover?
If the answer to all three is yes, you'll own what you paid for. If any answer is vague, that's the thing to pin down before money changes hands.
This is how I work as a default: custom tools built for your exact workflow, handed over with the code, docs, and keys, on a stack you're free to take anywhere.
Start a project if you want a tool you actually own.