What exactly do we get at the end?

Here is the list. Hold any supplier to it, including me.

The deliverables

• The working system, live, in your infrastructure, with your team using it.
• The code, in a repository in your name, with the history intact.
• Access to everything — hosting, database, domain, provider accounts — as the owner, not as a guest.
• Technical documentation written for a developer who has never met you: how it runs, how to deploy it, what the moving parts are.
• A user guide for the people who actually use it, covering what is live now rather than what is planned.
• A record of the decisions — why things were built the way they were, so the next person does not undo something deliberate.

The one people forget to ask for

A business continuity note. What happens if it stops. Who to contact, what to check first, how to get back to a working state.

One client asked for exactly this and framed it perfectly: someone is going to audit me at some point. He was right, and it is a reasonable thing to want regardless of audits.

When you get it

Documentation written at the end, in a rush, is bad documentation. It should be produced as the build completes, section by section, and the user guide should cover what is actually live rather than the full eventual vision.

If a supplier says documentation comes after go-live, ask when. Then ask again in a month.