Having software built? How it stays truly yours

The question behind the question

You’re having a website, portal or web app built. The proposals talk about features, planning and price — understandably. But the question that matters most in the long run is rarely in there: who owns it afterwards, and can you move on without the builder?

Whoever asks that question only when the relationship starts to pinch, is too late. That’s when the code turns out not to be transferable, the accounts are in the builder’s name, or nobody knows how the system fits together. Not because anyone planned it that way — it happens by itself, when nobody arranges it.

Where dependency comes from

Dependency has three sources, and none of them requires bad intent:

• Knowledge stays in heads. The product works, but how and why is written down nowhere. Every change has to go through the person who built it — and that person isn’t always available.
• The environment isn’t yours. Domain, hosting, email, external services: if those accounts are in the builder’s name, you literally can’t reach your own product.
• Nothing was agreed. Without an agreement about ownership, the question “whose code is this?” is unclear at best — and unclarity always works against the party that wants to leave.

Separately they’re inconveniences. Together they form a lock on your own software.

What “yours” means in practice

“It becomes your property” sounds good, but ownership is only real when you hold three things:

• The code and the environment. The source code lives where you can reach it, and domain, hosting and accounts are in your name. You give the builder access — not the other way around.
• The documentation. What’s there, why it’s set up this way, and how to change it. Not as a thick manual, but as working explanation alongside the product itself.
• The knowledge. Handover is part of the delivery: your team (or a next builder) can make a change without having to reconstruct everything first.

The test is the same as with AI systems: can someone else continue tomorrow without calling the original builder? If yes, it’s yours. If no, you have a subscription to a person.

What to agree before you start

This belongs on paper before a single line gets built:

1. Ownership transfers — the rights to what’s made for you, at the latest upon full payment.
2. Documentation is part of the delivery — not extra work or aftercare.
3. Everything in your name — domain, hosting and accounts from the very start.
4. Open foundations where possible — standard languages and open-source building blocks, so any capable builder can take over.

That’s how I work myself, and it’s written into my terms and conditions: what I make for you is yours — code, configuration and documentation. That’s not a favor but a normal agreement, and you may ask it of any builder.

Pace without rushing

There’s a persistent image that pace and care bite each other: whoever delivers quickly must be sloppy, whoever builds solidly must be slow. In practice, progress and transferability come from the same source — a clear foundation.

I build AI-assisted, but the real pace is in what doesn’t have to be done twice: every choice is recorded the moment it’s made, every week you see a working delivery, and the documentation grows along instead of being written afterwards. The result is software that advances steadily and stays transferable — because recording things isn’t a documentation chore, but the way of working itself.

See the AI-native digital delivery service

If you’re already locked in

Already have a product you can’t properly reach? Start by taking stock instead of escalating: where does the code live, whose name are the domain and hosting in, what documentation exists? Then simply request what’s missing — a large part can usually be arranged without any argument, especially if you approach it reasonably.

After that you’ll know what’s genuinely missing, and whether it can be solved with the current builder or with a next step. Want a second pair of eyes on that? Book a call via the button above, or browse the projects first to see what transferable work looks like.