What you should own at the end of a software project

The phone call that should not be scary

An owner's developer stops answering email. The tool he built three years ago still runs the job board, the timesheets and much of the invoicing. It works fine. Then one morning it does not, and the owner realizes he does not know where it is hosted, who pays for the server, what the password is, or whether the code exists anywhere he can reach.

That call is scary because of decisions made at the start of the project, not the end. Nobody asked who would own what. The developer set things up the fastest way, which was under his own accounts. It worked for years, so nobody thought about it.

The fix is not to avoid custom tools. It is to know exactly what you should own when the project ends, and to write it into the contract before it begins.

Your data and your accounts

This one sounds obvious, and it is where the most trouble hides.

Owning your data means more than a promise that it is yours. It means you can get it out, in a format another system can read, without asking permission or paying a fee. It means you know where it is stored and who can reach it. And it means you know what happens to it when the engagement ends, including how and when the vendor deletes their copies.

Ask to see the data map before signing. It should show what the tool stores, where each piece lives, where it comes from and where it goes. If AI models will see any of your information, the map should name the providers.

Then test the export once, early, while everyone is still friendly. Ask for a full export of your data and open it. Can you read it? Are the customer records, jobs and photos all there, and linked to each other in a way another system could make sense of? An export that arrives as a pile of files with no explanation is technically your data and practically useless.

Every tool runs on accounts: hosting, the database, the domain, email sending, file storage, any AI provider. Whoever holds those accounts controls the tool, no matter what the contract says about code.

The production accounts should be in your company's name, paid by your company, with your people holding the top-level access. The vendor gets access to do their work. When they leave, you revoke it, and the tool keeps running.

This is the piece most often skipped, because it is easier for a vendor to use their own accounts during the build. That is fine for a test environment. It is not fine for the thing your crew uses every day. If your production tool lives in someone else's account, you have a dependency, not an asset.

Your code, in writing

Paying for software does not automatically mean owning its copyright. When an outside developer or firm writes code, they can keep the copyright unless a written agreement transfers it. How that applies to your own contracts is a question for your attorney, and it is worth asking before the next project starts, not after. A handshake or an invoice marked "paid" is not the same thing.

What you want is a written copyright assignment for the bespoke tool, effective when you pay. That is how our contracts work: the client owns the data, the production accounts and the bespoke tool after payment, with the copyright assignment in writing.

There is a fair limit to this. A firm that builds many tools develops methods, templates and general components it uses on every job. Those stay with the firm, the same way a contractor keeps their tools when the house is finished. What matters is that the thing built for your workflow, with your rules and your screens, belongs to you, and that nothing the firm keeps is required to run it without them.

Ownership also means the code lives somewhere you control. A written assignment for code that sits only on the developer's laptop is a legal right with no practical value. The source should be kept in a repository under your company's account, updated as the work happens, not handed over as a zip file on the last day. And it should be possible to build and deploy the tool from that source using only what is written in the runbook. If a step only works from the developer's machine, you do not fully own the tool yet.

A handover pack someone else could use

Owning code you cannot run is not much better than not owning it. The last piece is documentation good enough that another developer, a future hire or a different firm could pick the tool up without calling the person who built it.

Our handover pack has five parts. The architecture describes how the tool is put together and why. The runbook says how to deploy it, restart it, back it up and recover it, written for someone who has never seen it. The credentials inventory lists every account and key the tool depends on and who holds each. The data map, described above. And the list of AI models and providers the tool uses, so you know who touches your information and can change providers later if you choose.

The pack should be updated on every release, not written once at the end and left to go stale. A runbook that describes the tool as it was eight months ago is a trap.

Here is a simple test. Hand the pack to someone who has never seen the tool and ask them how they would restore it from backup. If they cannot answer from the pack alone, it is not a handover pack.

It is worth doing this test for real at least once, not just in theory. Pick a quiet week, have someone other than the builder follow the runbook to restore a copy of the tool somewhere safe, and see where they get stuck. Every place they get stuck is a gap in the pack. Fix it while the builder is still around to explain.

Why this matters more for a small company

A large company has an IT department that asks these questions by habit. An operating company with a few office staff usually does not. The tools that end up running your business often start small: a scheduling sheet, a quoting form, a job board built by a friend of the family. By the time they matter, nobody remembers how they were set up.

That is how a tool becomes the system of record by accident, and how one person becomes the only one who can keep it alive. Owning the pieces above is what turns a custom tool from a risk into something you can hand to the next person.

None of this requires distrust of the people who build for you. Most developers who set things up under their own accounts did it to move fast, not to hold anyone hostage. Clear ownership protects them too. It means that when they want to move on, they can hand over a tool that keeps running, instead of being the one person who can never leave.

What to do next

Make a list of the tools your company depends on, including the small ones. For each, answer four questions. Who holds the accounts? Where is the data, and can you export it? Is there a written assignment for the code? Could someone else run it tomorrow? Any "no" is worth fixing before it becomes a phone call.

If the answer to that last question is that one person holds it all together, read the guide on the business stopping when one person is out. Our own ownership terms are on How we work.