Your site and system: are they really yours?
Nine questions about domain, code, hosting and access. At the end you get a summary you can print and take to your vendor, with the exact wording of what to ask. This is not a test that accuses anyone: any answer that is not a clear yes is simply a question worth asking.
Nine questions about who really holds your site or system. There is no score here that accuses anyone: any answer that is not a clear yes is simply a question worth asking your vendor.
0 of 9
Is the domain registered in your name, in an account you can log into?
Is there a code repository you own (not a ZIP file in an email)?
Is the hosting in your own account, paid by you directly?
Do you have a written list of every access, with a user of your own?
Can you export your data yourself, without asking permission?
Have you actually run one export, rather than been told it is possible?
Is the site built on something another developer could continue?
If you stopped working with your vendor tomorrow, would the site keep running?
Are ownership and handover written into the contract, not just said aloud?
Answer a few questions to get your summary
Why an ownership test is needed at all
Most owners sign a contract that talks about design, a number of pages and a timeline. Almost no contract talks about the day after. And that is exactly the day that decides whether you bought an asset or rented a flat without noticing.
The question almost never gets asked in time, because at the start there is no reason to suspect anything and by the end you have no leverage left. This tool exists to move the check to the point where it is still worth something: now, rather than on the day you want to move to someone else.
Where the nine questions came from
They are not a theoretical list. Each one is a point where I have seen a business get stuck: the domain registered in the vendor's name, code that exists only on somebody's laptop, hosting in an account you have no password for, the export everyone promises and nobody has tried. I set out the full reasoning in four tests for code ownership, and the contract version in the handover checklist.
This is not a test that accuses anyone
That matters to me, because a tool like this could easily become a suspicion machine. An answer that is not a yes does not mean anyone cheated you. It means there is an open point, and it is worth asking about. Plenty of decent vendors have simply never been asked.
So the output is not a red score. It is a list of questions, in precise wording, that you can take into a conversation. A serious vendor answers all of them without getting defensive, because they have good answers. Anyone who starts squirming has already told you something.
What to do with the summary
At the end of the test there is a print button and a copy button. Print gives you a clean page you can save as a PDF and email; copy gives you text you can paste into a message. Both work without leaving me a single detail about you.
The best move is to send it to your current vendor before the next payment, not after. Before a payment you have leverage; after it you have a request. That holds even if your vendor is excellent, because answers in writing are worth more than promises out loud.
A clarification, and a disclosure
I am not a lawyer and this is not legal advice. It is a practical list of questions from someone who builds sites and systems and sees at close range what stays in the client's hands when the relationship ends.
And full disclosure: I sell exactly the thing this test checks, so I have an interest in you finding a problem. Which is why you should notice that the test does not send you to me. It sends you to a conversation with the vendor you already have, and in most cases that is the right conversation.