A business hires a developer. The work gets done. Then the relationship sours, or the rates go up, and the owner finds out they can’t leave.
The hosting account is in the agency’s name. Nobody will hand over the passwords. The site runs on something custom that no other developer can make sense of, and there’s no documentation anywhere.
None of that is an accident. Somebody made those choices on the client’s behalf, and every one of them makes leaving expensive.
Here are the questions to ask before you sign. They take a minute to answer, and how a vendor answers them tells you as much as what they say.
Whose name goes on the accounts?
Hosting, your domain, and every third-party service your site depends on should be registered to your company and billed to your card. The developer gets access as a collaborator, which you can revoke whenever you want.
Watch for the vendor who offers to buy the domain “for convenience.” A domain in someone else’s account is the hardest thing on this list to get back.
Ask: which accounts will be in my name, and which ones will be in yours? Anything in theirs is leverage you handed over at kickoff.
Where does the code live, and starting when?
The answer you want is a repository your company owns, from the first week, with the full commit history in it. A zip file at the end of the project isn’t the same thing.
History is what tells the next developer why the code looks the way it does. Without it, they’re guessing, and you’re paying for the guessing.
Ask: on day one, can I log in and see the code? If the honest answer is “not until you set up an account,” that’s fine, as long as there’s a date for moving it.
What documentation do I get, and who is it written for?
You need two sets, because two different people need them.
Your team needs instructions written for someone who isn’t a developer: how to run it, how to update it, and what to do when the usual answer doesn’t work.
The next developer needs engineering notes: how it’s built and why, what the tradeoffs were, how to set it up locally, and how to publish changes. That second set almost never exists, and it’s the difference between hiring someone else and starting over.
Ask: can I see a redacted example from another project? Vendors who write real documentation will have one. Vendors who don’t will describe it instead.
What happens if we part ways?
Offboarding belongs in the contract, written down while everyone still likes each other. Waiting until you’re annoyed with each other is how a two-hour handoff turns into a six-week negotiation.
Ask: what’s your offboarding process, what’s included, and what does it cost? A vendor who has never thought about this will say so in the pause before answering.
How much of this is custom, and does it need to be?
Custom code isn’t the problem. Custom code doing something a standard tool already does, built in a way nobody else recognizes, is how a site becomes difficult to manage.
Ask: if I hand this to another developer next year, what will they need to learn before they can work on it? A short list is a good sign. A long one might still be justified, but you should hear the justification.
The pattern
Every item here is cheap to get right at kickoff and expensive to fix later, which is exactly why it gets skipped.
I’ve spent a lot of hours untangling projects where none of it was true, which is why project rescue is a service I offer. The clients who never need it are the ones who asked these questions before they signed.
