Five things to check today, in order, and what to do when the answer is no to most of them. Plus how to make sure it cannot happen with the next vendor.
Key Takeaways
- Five things to check today, in order, and what to do when the answer is no to most of them.
- Plus how to make sure it cannot happen with the next vendor.
The short answer
Before anything else, establish what you actually control: the domain, the DNS, the hosting, the source code, and the database. Most businesses in this position discover they hold two of the five, and which two decides how bad the next month is.
Do that audit today, even if your vendor is perfectly reliable. The worst time to find out you do not own your domain is when the person who registered it has stopped answering.
The five things to check, in order
1. The domain
Log in to the registrar. If you cannot, you do not control your domain, and that is the most urgent item on the list, because it controls your email as well as your website. Moving a domain away from an unresponsive registrant is slow and occasionally impossible.
2. DNS
Separate from the registrar, and often held somewhere else entirely. Whoever controls DNS can point your name anywhere, including away from you.
3. Hosting and the server
Can you log in to the server or the hosting panel? Is the hosting billed to your card or theirs? A hosting account that lapses because the vendor stopped paying takes your site down with no warning and no recourse.
4. The source code
Is there a repository you can open right now? If the only copy of the code lives on the vendor's laptop, you do not have a software asset. You have a running instance that nobody can change. Our note on what owning your source code actually means covers what to ask for.
5. The data
Can you take a database dump yourself? Not "can they send you one", but can you, today, without asking. The data is usually the only part that cannot be rebuilt.
If the answer is no to several of these
Work in this order. Secure the data first, by any legitimate means available, including the application's own export features if that is all you have. Then secure the domain, because it is the hardest to recover later. Then worry about the code.
If the site is running and you cannot get the source, a rebuild is often faster than a forensic recovery, particularly for a marketing site. For a system holding years of records it is the reverse: the data matters far more than the code, and new code can be built around it.
Resist the urge to change every password on a system you do not understand. Write down what you have access to first. Locking yourself out of your own running system in the first hour is a common and entirely avoidable mistake.
Making the next one impossible
- Register the domain yourself, in your company's name, on your own card.
- Own the hosting account. Give the vendor access to it rather than taking access from theirs.
- Require a repository you can read from day one, not at handover.
- Take your own backup periodically and confirm it actually restores.
- Put all of it in writing before work starts. Our note on contracts covers the clauses.
None of this is adversarial. Any vendor worth hiring expects all five and will not blink when you ask.
Frequently asked questions
My developer registered my domain and will not respond. What now?
Contact the registrar directly with proof the business is yours: registration documents, payment records, correspondence. Registrars have dispute processes. They are slow, so start immediately rather than waiting to see whether the developer replies.
Can I get my source code if it is not in writing?
Sometimes, by asking plainly and paying for the time. Often not. Without a written assignment your position is weak, which is the whole reason the clause matters before work starts rather than after.
Should I rebuild or recover?
Rebuild if the system is mostly presentation. Recover if it holds data and history. The answer is usually obvious once you ask which part you would miss in a year.
How do I take over a system I did not build?
Expect to pay for a discovery period before anyone quotes on changes. Any firm that gives a fixed price to modify a system it has not read is guessing, and the guess will be wrong in one direction or the other.
How do I avoid this with the next vendor?
Own the accounts, require the repository, take your own backups, and put it in the contract. The ten-point vendor checklist covers the rest of what to ask before you sign.
Enjoyed this article? Share it with others!
Written by
Antbytelabs
Writing about the software we build at Antbytelabs in Bhaktapur, Nepal.