You have the code. That is not the same as owning the system.

Most of the custom software running inside a business was built by someone who no longer works on it. An agency took the project, or a contractor did, or a capable person who has since been promoted into a job with no time for it. The build itself went fine. There was a handover call, a copy of the code, and a document with the logins in it.

The trouble arrives later, and it arrives small. Someone needs a field added to a form, or a phone number changed in an email template, or the model the system calls is being retired and has to be swapped. That is when a lot of firms discover that what they own is a system that runs — not a system they can change.

What a handover usually contains

I have been on both sides of these. The handover a conscientious developer gives you is honest and still not enough, because it is assembled from what they remember needing — and they have not needed the hard parts in two years. They set the cloud account up once, with their own personal login, and have not thought about it since.

So you get the artefacts: the repository, a README, an architecture diagram, a spreadsheet of credentials, and an hour on a call that mostly covers how the admin screen works. What you do not get is the thing that decides whether you are stuck: a demonstrated route from a change on someone’s laptop to that change being live, walked end to end by someone who is not them.

Ownership is a path to production, not a pile of files

The accounts are the asset. The cloud account, the domain registrar, the app stores, the payment gateway, the service that sends your email. If any of them sit under a personal address, you have not been given that part of the system. You have been lent it.

Secrets are never in the code. API keys, database passwords, signing certificates — these are injected at deploy time and kept wherever the developer kept them. A repository with no secrets in it is correct practice and, on its own, unbuildable.

The build runs on one laptop. There is almost always a sequence of steps, specific versions and one undocumented workaround that got it building. None of it is written down, because the person doing it never had to.

The domain is the off switch. DNS decides where your customers land. Whoever controls that account controls the business, whatever the contract says about who owns the code.

AI systems strand you faster

A conventional web app you cannot change is at least stable. It keeps doing tomorrow what it did yesterday. An AI feature does not extend you that courtesy, because the parts that matter most sit outside your repository and move on someone else’s schedule.

The keys are on a personal account. Model-provider billing takes a card and an email address, so during a build it frequently gets one of the developer’s. That account is also your spend limit, your usage log and your ability to revoke.

The prompt is not in the code. On most systems I am asked to look at, the text that decides what the thing actually does lives in a database row or an admin field. I have written before about who should be allowed to change it. The prior question is whether anyone at your end can.

Models are retired on a timetable. Providers deprecate versions with months of notice, not years. A system nobody can deploy cannot have its model swapped, which turns a published retirement date into a scheduled outage.

Nobody kept the examples. The cases the build was tuned against — the awkward documents, the outputs that had to be right — were in someone’s head or a chat thread. Without them your next developer cannot tell whether a change improved the system or quietly broke it.

The bill continues either way. The usage cost of an AI feature arrives every month whether or not anyone can touch the system generating it, which is the other half of what an AI feature costs to run.

Ask while everyone is still friendly

The time to fix this is the week you are signing, not the week they leave. None of it is an unreasonable thing to ask for, and a developer who resists any of it has told you something useful for free.

Every account in the company’s name. Created with a company email address, billed to the company card, with the developer added as a user rather than as the owner. That single change removes most of the exposure.

A deploy by someone who did not build it. Put it in the contract as an acceptance condition: a second engineer, following the written runbook, puts a trivial change live. If the runbook is wrong you find out while you are still paying.

Secrets in a store you hold. Your own password manager or secret store, with the developer given access rather than custody.

The test cases, not just the code. The examples and sample documents the system was judged against, committed to the repository with everything else.

If you have no technical person to judge whether you got these, ask an independent engineer to check them in an hour — asking for the right four things beats a long document nobody checks.

The change I would make this week

What you are measuring is not whether the change shipped. It is how many people outside your company had to say yes before it could, and whether any of them is under any obligation to keep saying yes.