What you should get when a development project ends

The end of a project is where a lot of goodwill quietly disappears. The software works, the invoice is paid, and six months later you need a change — and discover the original developer still owns the hosting account, there’s no documentation, and nobody knows which of three environments is live.

This is the list to agree before the project starts. Any competent developer will say yes to all of it; the ones who hesitate are telling you something useful.

Code and infrastructure

• The repository, transferred to you or with you as owner. Owner, not collaborator. Being a collaborator on someone else’s account is not ownership.
• Hosting in your account, billed to you. If it sits on the developer’s account, you don’t control your own product.
• Domain and DNS under your control.
• All third-party accounts in your name — payment processor, email service, any API.
• A documented, repeatable deployment process. Not one that only works from one laptop.

Documentation

• How the system works, in plain language, not just code comments
• How to make the changes you're most likely to want
• Known limitations and the trade-offs that were made deliberately
• Where the data lives and how backups work

A recorded walkthrough

A live walkthrough is standard. Ask for it recorded — thirty minutes of screen recording. Six months later, when the person who attended has left, the recording is the only thing that still knows how the system fits together.

The two people forget to ask for

1. A software bill of materials

A list of every third-party component in your software and its licence. This matters for a reason that only shows up much later: open-source licences carry obligations, and a copyleft component buried in a proprietary product is the kind of thing that surfaces during acquisition due diligence, years after the developer has moved on.

It matters more now that most code is written with AI assistance, because those tools learn from public code and can reproduce parts of it. Ask whether a licence scan was run and ask to see the result. We explain how we handle this in how we use AI.

2. Confirmation that their access was removed

When a project ends, the developer’s access should be removed or cut back to whatever the support window needs — and they should confirm in writing that they’ve done it.

This protects both sides. You reduce the number of people holding keys to your systems, and they stop being a live credential holder for a system they no longer maintain. Almost nobody asks for it.

Commercial

• Clarity on when IP transfers. Standard practice is on full payment. Make sure it’s written down.
• Written acceptance against criteria agreed at the start — not invented at the end.
• Support window dates, and what’s covered. “Thirty days of support” means little until someone defines whether a new feature request counts.