Who owns the system after it is built?

Source code

You should own it outright on final payment, with the right to modify it and to give it to somebody else. Get that in writing before work starts.

Watch for a licence dressed as ownership: a right to use the system is not the same as owning what it is made of, and the difference only becomes visible when you want to change supplier. Watch too for a shared framework the supplier reuses across clients — that can be perfectly reasonable, but you need to know which parts you own and which you are licensing.

Hosting and accounts

The server, database and any third-party services should sit in accounts you own and pay for, with the supplier holding access. Not the reverse.

When the supplier owns the account, a billing dispute or a quiet disappearance takes your system with it, and recovering from that is far harder than it sounds. Paying the hosting bill directly costs no more and changes who holds the keys.

Credentials

Every API key, token and password the system uses should be recoverable by you without asking anyone. Ideally you issued them.

This is the one people skip, and it is the one that hurts. A system that authenticates to five services using keys only the supplier holds is not really yours regardless of who owns the code.

Documentation, and what it should contain

Not a manual. Enough for a competent engineer who has never seen the system to pick it up:

• What it does, in plain English, and what it deliberately does not do
• Where it runs and how to deploy a change
• Which external services it depends on and what happens when each is unavailable
• The rules it applies, and where they live so they can be changed
• How to tell whether it is working right now

That last point matters more than the rest. A system nobody can check is a system nobody can trust, which is why every build we do records each decision with the reason behind it — the reasoning is set out in how it works.

What maintenance actually covers

“Support” means very different things. Pin down which of these are included: keeping it running, fixing defects, adapting to a third party changing their API, updating the rules when your policy changes, and building new capability.

The first four are maintenance. The fifth is a new project. A supplier who blurs that line will either resent you or overcharge you, and often both.

Whether that is charged as a retainer, a day rate or per item changes the incentive as much as the amount does — per-item pricing versus day rates sets out what each model rewards.

The question people are too polite to ask

What happens if you are unavailable?

With any small supplier, including this one, that is a fair and necessary question, and the answer should be structural rather than reassuring. If you own the code, own the hosting, hold the credentials and have documentation a competent engineer can act on, then the answer is: you engage somebody else, and it is an inconvenience rather than a catastrophe.

A supplier whose answer is “that won't happen” has not answered. One who has made themselves replaceable on paper is the one worth hiring — and if you want to test that in a conversation, book a call and ask it directly.