The handover: what you must receive from a development partner

Ten things have to arrive at handover, and all ten belong in the contract before anyone writes code. The repository with its real commit history, not one squashed dump. Legal ownership of every account — cloud, registrar, app stores, payment processor, transactional email, analytics — in your company's name. The domain, at a registrar where you are the registrant of record. A documented path from a clean machine to a running local environment. The deployment pipeline and the secrets it needs, in your control. An identifiable archive of what is actually in production, with a list of its components. A runbook for the things that break at 3am. Your data, plus an export path you have run yourself. The third-party contracts, in your name, with renewal dates. And a written definition of done, agreed before the first sprint, which is the item that makes the other nine happen.

Here is the part that surprises founders: most handover disasters are not code-quality problems. They are ownership and access problems. Bad code is a known, payable cost — you can read it, test it, refactor it and hire against it, because it is in your hands. An account nobody at your company can log into is a hard stop that no amount of engineering talent fixes. You cannot refactor your way into being the registrant of your own domain, or rewrite your way into the payment processor account holding your customers' saved cards. Code is the asset everyone negotiates over. Access is the asset that decides whether you can keep operating without your vendor.

Start with the repository, because it is the item most likely to arrive technically complete and practically useless. A single "initial commit" containing sixty thousand lines is not a history; it is a photograph. What you lose is not sentimental: you lose the ability to bisect — to find the commit where a behaviour changed by mechanically testing halves of the timeline — and you lose attribution, which is how you work out who to ask and what was deliberate. NIST treats that accountability as the reason version control exists. Its Secure Software Development Framework states practice PS.1.1 as "Store all forms of code – including source code, executable code, and configuration-as-code – based on the principle of least privilege so that only authorized personnel, tools, services, etc. have access," with the implementation example "Use version control features of the repository to track all changes made to the code with accountability to the individual account" (NIST, SP 800-218, Secure Software Development Framework Version 1.1, February 2022). The check takes ten seconds: clone the repository, count the commits, read the dates. A ten-month build with fourteen commits all dated last week was developed somewhere else and copied in.

Credentials are not ownership, and the difference is the most expensive item on this list. A vendor can hand you an administrator login that does everything you can imagine needing, and you can still not own the account. Amazon documents the boundary plainly: to change the root user email address on an AWS account, "You must sign in as the AWS account root user, which requires no additional IAM permissions. You can't perform these steps as an IAM user or role" (Amazon Web Services, Update the root user email address, AWS Account Management Reference Guide). An IAM administrator key is a powerful tenant; the root identity is the landlord. The same documentation describes how, for a member account inside an organisation, a user in the management account or a delegated admin can centrally update that account's root email. So the test is not whether you have a login. It is whether you can change the root email today, alone, and whether the account sits in an organisation you control.

The domain is where lateness becomes a lock, so fix it first. Registrant details are governed by transfer rules that do not care about your launch date. Cloudflare, documenting the ICANN requirements for bringing a domain in, lists as conditions that "Your domain was registered at least 60 days ago and has not been transferred in the last 60 days (ICANN requirement)" and that "You have not changed your registrant name, organization, or email address in the last 60 days. Under ICANN rules, changes to these fields trigger a 60-day transfer lock" (Cloudflare, Transfer a domain to Cloudflare, Cloudflare Registrar documentation). Read that twice, because it is counter-intuitive: correcting the registrant name from your vendor's to yours is itself the event that freezes the domain for two months. Discovering it during a contract dispute is the worst possible moment.

Environment reproduction is a test, not a document. The deliverable is not a README; it is a demonstrated run. Take a machine that has never touched the project, hand it to an engineer who did not build the system, start a timer, and follow the written instructions to a working local environment with seeded data. Every question that engineer has to ask is a gap, and their questions are the actual content of the missing page. The same framework treats environments as first-class — practice PO.5.1 is "Separate and protect each environment involved in software development" — which only means anything if the environments are described somewhere a new person can read.

An archive of what is in production, and a list of what it is made of. Deployed code drifts from the tip of the main branch: a hotfix, a rollback, a configuration change made in a console at midnight. So you need the actual release — the artefact, its version, its dependencies. NIST states this as two practices worth quoting to a vendor verbatim. PS.3.1: "Securely archive the necessary files and supporting data (e.g., integrity verification information, provenance data) to be retained for each software release." PS.3.2: "Collect, safeguard, maintain, and share provenance data for all components of each software release (e.g., in a software bill of materials [SBOM])." A bill of materials turns the next critical dependency advisory from a week of archaeology into a query, and PS.2.1 — "Make software integrity verification information available to software acquirers" — names you, the buyer, as the party it exists for.

The runbook decides your first bad night. It is not architecture documentation. It answers, in order: how do I know something is wrong, and what tells me? Where are the logs, and how do I find one request in them? How do I restart this safely, and what must not be restarted? Where are the backups, when was a restore last actually tested, and what was the measured recovery time? Which third parties can take the system down by themselves? Who is the human at the vendor, and what does the contract say about response time? A runbook nobody has used in a rehearsal is a draft — so run one incident drill during the engagement, while the people who built the system are still being paid.

Data, and an export path you have personally executed. Ownership of data in a contract is not possession of it. Ask for a full export in a documented format, run it yourself, then load it somewhere else. That last step surfaces the real problems: identifiers meaningful only inside the application, uploaded files referenced by URLs pointing at a bucket in someone else's account, an audit trail that is not in the export at all. Do this at the halfway point of the build rather than at the end, because halfway it is a bug report and at the end it is a negotiation.

Third-party contracts, and whose name is on them. Every production system rents things: the payment processor, the email and SMS providers, the mapping API, the error tracker, the app store developer accounts, DNS and certificates. Each is a contract with a legal party, a billing card and a renewal date. When those sit in your vendor's name you have a dependency whose terms you cannot read, and app store accounts are the sharpest case — moving a published mobile app between developer accounts is governed by the store, not by your contract. Ask for the list with owner, billing party and renewal date in three columns, at the start, when it is merely a form to fill in.

Now the item that makes the other nine real: what done means, in writing, before you begin. A handover clause written at the end of a project is written by whoever has more leverage, and that is rarely the buyer with a launch date. Written at the start it is uncontroversial, because no vendor refuses to name artefacts before they have a reason to withhold them. The incentive is worth stating plainly, and it applies to us: an engineering firm's commercial interest is served by a vague handover, because vagueness converts into a support retainer. If the handover artefacts are not listed in the proposal, the handover has not been planned — and the retainer that follows is not a service, it is a dependency.

This has become sharper for first versions built with AI coding tools, which is now the ordinary case. The generated code is frequently fine; what is missing is everything on this list. No commit history worth reading, because the tool committed in bulk. No runbook, because nothing has broken yet. No export path, because nobody has needed one. Accounts opened under whichever personal email was convenient. The Stack Overflow 2025 Developer Survey suggests why the cleanup is worse than it looks: 66% of developers name "AI solutions that are almost right, but not quite" as their biggest frustration, 45% report that debugging AI-generated code is more time-consuming, and more developers actively distrust the accuracy of AI tools (46%) than trust it (33%) (Stack Overflow, 2025 Developer Survey: AI). Almost-right code with no history attached is the most expensive thing to inherit, because you cannot tell which decisions were decisions.

Organisations with a mandate and an auditor are not much better at this. The US Government Accountability Office notes in its Agile Assessment Guide that "all too frequently, agency IT programs have incurred cost overruns and schedule slippages while contributing little to mission-related outcomes," against federal IT spending of more than $90 billion annually (US Government Accountability Office, Agile Assessment Guide, GAO-20-590G, September 2020). Those programmes have contracting officers, data-rights clauses and statutory oversight. A founder with a signature and a deadline has none of it, which is why the checklist has to live in the proposal rather than in the goodwill.

Every item above is also a question you can ask during selection, and the answers separate firms faster than a portfolio does. A partner who commits to your repositories from day one, opens accounts in your name and lists handover artefacts in the proposal has removed the handover as an event — there is nothing to hand over because nothing was ever held. That is one of the criteria any top saas development company can be tested against before signing, and the same discipline is what makes a startup software development company safe to leave. Nine of the ten items cost an afternoon at kickoff and a great deal on the last day; only the runbook, the archive and the export need real work, and they need it during the build. If you are still upstream of all this, how to scope an MVP so it ships and what an MVP build actually costs come first — but put the handover clause in the same document. For a system where none of this could be left to the final week, a 150-branch student information system delivered over 22 months is the honest example, and our product engineering work is structured so the repository and the accounts are yours from the first commit.