What You Actually Own When the Project Ends
What happens if the freelancer disappears? The seven things your company should own from day one, and the four questions that get them.
Every company that has thought seriously about hiring a freelancer instead of an agency has run into the same worry, usually without saying it out loud.
What happens if he stops answering the phone?
It is a fair question and it deserves a straight answer rather than reassurance. The honest one is this: the risk is real, and it has very little to do with whether you hire one person or twenty. It has to do with what you own when the work is finished.
A five-person agency that holds your code, your accounts and your data is a worse risk than one freelancer who hands you everything as he goes. Continuity is not a headcount. It is a list of things that are in your name.
The seven things that should be yours
Go through this list for any software you are paying someone to build. If you cannot tick all seven, the gap is where your exposure lives.
The code, in your repository. Not sent as a zip at the end. A repository owned by your company, with the developer added to it, from the first week. This one change removes most of the risk on the list by itself.
The domain. Registered to your company, paid on your card. It is the cheapest item here and the most painful to recover when it is registered to somebody else.
The hosting and the database. In an account your company owns, billed to your company. A developer having access is fine and normal. A developer being the account holder is not.
The third-party keys. Every paid service the system talks to should be your account with your billing. When these sit in a builder's personal account, your software stops working the day that relationship ends, and often without warning.
Your data, exportable today. Not in theory, not on request. Ask for an export now, while everyone is friendly, and check that you can actually open the file. A system you cannot get data out of is a system you cannot leave.
Deployment access. Someone at your company should be able to see where the thing runs and get back into it. They do not need to know how to deploy. They need to not be locked out.
The one page of documentation that matters. Not a manual. One page that says where it runs, what it connects to, what is non-obvious, and what to do when it breaks. This is the difference between a new developer needing two days to get oriented and needing two weeks.
Four questions to ask before you sign anything
Ask these of anyone, freelancer or agency. The answers take a minute and tell you almost everything.
- Whose account is the code in, and can I add my own people to it today?
- Whose name and card are on the hosting, the domain, and the paid services?
- Can I export my data myself, right now, without asking you?
- If we stop working together next month, what exactly do I have?
The answers matter less than the reaction. Anyone who builds this way answers in thirty seconds because nothing needs arranging. Hesitation is the signal, not the content.
What a bad setup looks like
A few patterns worth recognising, none of them rare.
The system is built inside a platform that only the builder can access, so your options are to keep paying that person or start again. The hosting is on a personal account and you appear on no invoice. The code has never been shown to you and is described as proprietary, which for custom work you paid for is a strange thing to be told. The data lives somewhere with no export, so the only migration path is retyping it.
None of these require bad intent. Most of the time it is just how the person works and nobody ever asked. That is exactly why you should ask.
The honest trade-off
I will not pretend a freelancer and an agency are the same thing.
One person is faster, cheaper and talks to you directly. You are also one person's calendar and one person's health away from a pause. An agency has continuity and process, and you pay for that in money, in speed, and in the number of people between you and whoever is actually building.
The way to manage the freelancer risk is not to buy more headcount. It is to own the work as it is produced, so any competent developer could pick it up. When that is true, the difference between one builder and five is scheduling, not survival.
How I work, since it is the obvious question
Your repository from week one, with me added to it. Accounts in your company's name and on your billing from the start, not migrated at the end. Data export available whenever you ask. One page of documentation with every project, kept current.
I also build and maintain my own products, which is a useful thing to check when you are judging whether someone can support software rather than just ship it. Appblox and Bondo are both live on the App Store, both maintained by me, and both have had to survive an operating system release since launch.
If you are weighing up a build and want the ownership questions answered plainly before anything else, that is a five-minute conversation. Start with one process you want to fix.
