Who Owns My Website Code? Four Tests That Tell You

One of the most important questions a business owner forgets to ask is a simple one: who owns my website code? Here is a phone call I once got from a business owner, not a client of mine: "Someone built me an order-management system three years ago. Now I need a small change, and the guy who built it isn't answering. Moved abroad, I think. Can you get in and fix it?"

I asked him one question: "Is the system in your hands? Do you have access to the code, to the database?"

Silence. Then: "I don't know. It runs somewhere on his end."

That's the moment a business discovers it doesn't own the system it lives on. It's a guest in it. And like any guest, you can wake up one day to find the locks changed. In this post I want to unpack what "owning" a system actually means, why I believe in it enough to put it in writing as a commitment, and which questions you should ask anyone who builds something for you, including me.

Three ways to become dependent without noticing

Vendor dependence doesn't arrive with a warning sign. It comes in three forms, and each one looks innocent on the day you sign:

The system runs "on his end". The code sits on the vendor's server, in his account, under his name. As long as the relationship is good, everything works. The day he disappears, stops answering, or closes the business, your system disappears with him. Not always out of malice; sometimes life just happens.

Your data is locked inside. Even with a large, reputable service, it's worth asking: if I want to leave tomorrow, how do I take my client list, my history, my documents with me? Some services offer a full, orderly export. In others, the only way out is copying screen after screen by hand. You want to know that answer before you walk in, not when you already want out.

Only he understands how it works. No documentation, no explanation, everything lives "in the developer's head". Even if the code is in your hands, code nobody else can understand is ownership on paper only. That's dependence on a person instead of dependence on a company, and it's no less dangerous.

Who owns my website code? Four tests

Ownership isn't a clause in a contract. It's a technical fact, and you can check it with four simple questions:

• The access test: Do you have, right now, your own username and password for every place the system and the data live? Not "I can ask the vendor", but yours, in your hands?
• The export test: Can you download all of your data, clients, inquiries, history, in an open format any other system can read, without asking permission?
• The disappearance test: If the vendor vanishes tomorrow morning, does the system keep working? And could another reasonably competent developer step in and pick up where he left off?
• The explanation test: Has someone written down, somewhere, in plain human language, what the system does and how it's built?

Four yeses: you're an owner. Even one "no" is enough to give you a point of dependence, and you should at least know it's there.

"But why should I care? It works"

That's a fair argument, and I want to answer it seriously, not with scare tactics.

Most of the time, it genuinely doesn't matter. The system works, the vendor answers, life is good. Ownership, like insurance, feels unnecessary right up until the moment you need it. But notice when that moment arrives: always at the worst possible pressure point. When you need an urgent change and the vendor isn't available. When the price jumps and you have no choice but to pay, because leaving would cost more. When the business outgrows the system, but you can't take it to someone else to extend.

Missing ownership doesn't hurt day to day. It hurts exactly in the moments when the business is most vulnerable. And unlike a technical glitch, you can't fix it after the fact; you can only regret it. The way I see it, a business owner who paid for a system with hard-earned money should hold it in hand the same way they hold the keys to their own shop.

The common mistakes around ownership

Being embarrassed to ask. "I didn't want to seem suspicious." An ownership question isn't suspicion, it's professionalism. A serious vendor answers it gladly, because he has a good answer. Anyone who takes offense at the question has just answered it for you.

Confusing files with ownership. "I got a folder with the code by email" is nice, but code without the environment that runs it, without the passwords and without an explanation, is like an engine without a car. Ownership is the ability to keep operating and developing, not a file in an archive.

Thinking it's about vendor size. "It's a big company, there's no risk." Big companies don't disappear, true, but they do shut down products, raise prices, and change terms. With a large vendor, the key question isn't "will they still be around" but "how easily can I leave". The ability to walk away is the only leverage a small client has against a big company.

Staying locked in out of convenience. The most human mistake of all: you know the dependence is there, and you keep putting it off because everything works. But ownership questions are cheapest to sort out at the beginning, and every passing day makes them more expensive.

What you can do today

Even if you already have systems in place and no budget for any change:

Run every critical system in the business through the four tests above, not to act immediately but to know where you stand. Within half an hour you'll have something most businesses don't: a map of your dependencies. After that, ask every active vendor for the access credentials you're entitled to and one full export of your data, and keep it with you. A backup that sits in your own hands is the first and cheapest step toward ownership. And if someone is building you something new right now, bring the four questions into the conversation this week, while it's still easy.

When renting is actually fine

I'm not against subscription services, and not everything needs to be yours. Standard tools like email, calendar, and bookkeeping: the big services do them excellently, and trying to run them yourself would cost more than it gives. Renting only becomes a problem when it touches the heart of the business: the system that holds your clients, your inquiries, and the processes that are uniquely yours. The core deserves ownership; the edges you can rent. And even then, the data itself, in any service, has to pass the export test.

Why I put this in writing as a commitment

For me this isn't a slogan, it's how I work, which is why "the system stays yours" is written down in black and white. If you've read my post on the five signs your business needs one system, you know I build exactly these core systems for small businesses. What I build sits in the client's own accounts, with full access, with a written explanation, so it passes the four tests even against me. That's how I'd want someone to build for me. You can see how that works in practice on the services page.

If you want to run these tests on your own site right now, I turned them into a short ownership test. A couple of minutes, and you get a printable summary with the exact wording of what to ask your vendor.

You can also look at real examples of my work and judge for yourself. And if you're at the stage of figuring out what your business needs, the short questionnaire is a good place to start, with no commitment and no sales call.