Direct answer

Developer Client Handover

A developer client handover is one link that proves what actually shipped. The link carries the build or repository state delivered, the tests that ran and their results, the deploy step and where it landed, the known issues stated plainly, and a verifiable receipt for each recorded step. The client opens it with no account, checks the record against the acceptance criteria, and accepts the delivery or flags one step. It replaces the demo call, the it is live email, and the client quietly hoping the version they saw is the version they got.

Open a real one first: the worked example handover at zambo.dev/handover/bd7e5325-33fd-4c5e-b029-76b781fa2f51 is open and waiting on its client. The accepted example, handover 45434a17-4afc-486a-9646-e689bcee4297, was an end-to-end audit handover that a client accepted, and that acceptance minted its own receipt on the record. Check any receipt free at the public verifier. Start your own at zambo.dev/handover.

Updated October 20, 2026.

What a developer actually hands over

A software delivery is a state, not a screenshot. The client is receiving a specific build: a repository at a specific point, a deployed version at a specific address, a database and configuration set up in a specific way, and documentation that lets someone else run and maintain it. Around that core sit the delivery facts clients actually need later: which tests ran and passed, which environments were used, what access was transferred, which third party services the system depends on, and what is known to be imperfect in this version.

A handover packet names all of it in order. The agreed goal and acceptance criteria at the top. The build steps next, with their outputs: the checks, the test runs, the deploy. Then the access and documentation items as deliverables in their own right, because a system the client cannot log into or hand to another developer has not really been delivered. Finally the known issues and the deferred features, listed as open items, so acceptance means the client accepted this version with these known limits, not an imaginary flawless one.

Build deliverables: the repository state or build artifact delivered, identified precisely, with the deploy address where it runs.

Evidence deliverables: the test runs and checks that were executed against this build, with their results, each recorded step carrying its receipt.

Access deliverables: the accounts, environments, and services transferred or created for the client, listed so transfer can be confirmed item by item.

Open items: known issues, deferred features, and anything awaiting client input, stated in the packet instead of discovered later.

What clients check before they accept a build

A technical client checks the evidence: did the agreed tests run against this build, do the results in the packet match what they can reproduce, and does the deployed version behave like the staging version they approved. A non technical client checks differently, and their checks are just as rational: can I log in, can my team log in, does the thing do the three jobs I bought it for, and who do I call, with what information, when it breaks. Both kinds of client check the known issues list hardest of all, because it tells them whether the developer is leveling with them.

Clients also check the exit question, even when they do not say it aloud: if this developer disappears, can someone else pick this up. A packet that contains the build identity, the deploy record, the access list, and the documentation answers that question better than any assurance. Developers who hand over in this shape notice a side effect: clients ask fewer anxious status questions on the next project, because the first handover taught them what delivery from this developer looks like and that it can be checked without a meeting.

Where developer acceptance stalls

It stalls on works on my machine. The client tests the delivery, hits behavior the developer never saw, and there is no shared record of which build, which environment, and which data each side was looking at. It stalls on demo drift: the client approved what they saw on a call three fixes ago, the shipped build differs in ways nobody listed, and acceptance becomes an argument about whether a difference is a bug or a change. It stalls on silent known issues: a limitation the developer considered obvious surfaces in the client's first week, and because it was never written down as known, it lands as a defect in delivered work.

The deepest stall is acceptance criteria that were never tied to evidence. The agreement said the system shall handle refunds; the client reads that as partial refunds in the admin panel, the developer built full refunds through a support action, and both readings are honest. A handover does not rewrite the agreement, but it forces the confrontation to happen at delivery, item by item, while fixes are still cheap: here is the criterion, here is the step that addresses it, here is the test result, accept or flag this step.

The manual way, and why deploy emails fail

The manual handover is a message saying the build is live, a link, maybe a short loom or call recording, and a request to confirm. It fails on precision. Live as of when, at which version, with which configuration, are questions the email cannot answer a month later when the system has been patched twice and the client reports that something they accepted has changed. It may have changed, legitimately, but without a delivery record there is no baseline to compare against, so every later change looks like it might have been there, wrong, from the start.

Repository access alone is not a handover either. A repo shows the present state of the code, including every commit since delivery, and a busy repo makes the delivered state harder to find, not easier. Issue trackers show intent and discussion, not a decision. The handover packet is the missing layer between them: a fixed record of the delivery moment, the evidence gathered at that moment, and the client's decision on it, which stays readable no matter how much the code moves afterward.

The handover way, step by step

Build with tools connected to Zambo, the verifiable work layer for AI: the MCP endpoint at zambo.dev/mcp, one URL with no key, 153 tools in total and 35 on the default surface. Development work assisted in Cursor, Claude Code, Codex, Copilot, Windsurf, Cline, VS Code, or Zed, and checks run through connected tools, leave a verifiable receipt per recorded step. At delivery, assemble the handover at zambo.dev/handover: criteria, build identity, test evidence, deploy step, access list, documentation, known issues.

Keep secrets out of the packet entirely: list that an access item was transferred, never the credential itself, and redact keys, addresses, and personal data before publishing. Send one link. The client opens it with no account, checks any receipt free at zambo.dev/verify, and accepts the delivery or flags one step, so a defect report arrives already attached to the step it concerns. You cannot accept your own handover: the creating account is refused, so acceptance on the record is the client's decision about this build, usable later in any warranty or scope conversation.

Identify the delivered build precisely, and give the address where the client can run the deployed version.
Attach the test and check results that ran against this build, not against an earlier one.
List access and service transfers as items the client can confirm one by one, without putting any secret in the packet.
Write the known issues and deferred features into the open items, in words the client would use.
Map each acceptance criterion to the step and evidence that addresses it, or say plainly that it is open.

Two real records, and what each one shows

The open worked example, bd7e5325-33fd-4c5e-b029-76b781fa2f51, shows a packet awaiting its client decision, the software equivalent of a build sitting in acceptance testing. The accepted example, 45434a17-4afc-486a-9646-e689bcee4297, was an end-to-end audit handover, work whose entire value was methodical checking, and its client accepted it, minting a receipt for the acceptance. Audit work is a fair model for development delivery: the client could not watch every check happen, so the record of the checks, and the acceptance of that record, is what they actually bought.

Show both records to a prospective client during the sales conversation, not after delivery. A developer who can show, in advance, the exact shape of the evidence a client will receive, and a real accepted example of that shape, is answering the objection every client has and few voice: how will I know what I got. That answer, given early, changes the negotiation from price per hour to quality of delivery.

What the record proves, and what it does not

A receipt proves the saved result of a step was not changed after the fact. If the test output in the packet is the test output saved when the tests ran, the free check at zambo.dev/verify matches. It does not prove the tests were the right tests, that coverage was sufficient, or that the code is free of defects: a faithfully recorded weak test suite is still a weak test suite, and the packet will show exactly which tests ran, which is itself useful honesty. The acceptance receipt proves who accepted this delivery and when.

The record also does not replace a support agreement, a warranty, or a maintenance arrangement: it records the delivery those agreements refer to. AER-1, the open receipt format underneath, is an IETF Internet-Draft, draft-zambo-aer1-24, not a finalized standard. Developers, of all trades, should appreciate the discipline of a claim stated at exactly the size the evidence supports, because that is the same discipline the packet asks of a delivery: state what was built, show what was checked, list what is known to be open.

Variants: websites, automations, and internal tools

A website delivery weights the live address, the content as loaded, the forms and where their submissions go, and the analytics setup. An automation delivery, a workflow in n8n or a script that moves data between systems, weights the runs: the packet should carry example runs with their receipts, the schedule or trigger, and the failure behavior, because the client is accepting a system that will act when nobody is watching. An internal tool delivery weights access and documentation, since the users are the client's own staff and the next maintainer is the real audience for the handover.

For contract developers working inside a client's team, the same packet closes a sprint or a milestone: build, evidence, known issues, acceptance by the product owner. Using the shape consistently turns a series of milestone records into the project's delivery history, which is the document everyone wishes existed when a system is audited, sold, or rebuilt, and which almost never exists because nobody assembled it at the time. The handover assembles it at the time, as a byproduct of delivering properly.

What it costs

Public handovers are free to send and free for the client to open. For $0.99, a Day Pass covers 24 hours of full recorded work through the Zambo MCP, which fits a release day: final test runs, deploy, packet assembled, link sent. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402. Set against one disputed milestone payment, the arithmetic settles itself.

Honest limits

The packet covers steps that ran through connected tools. Tests run entirely locally and never recorded, manual checks on a device, and conversations about the build have no receipt, and an honest packet lists them as unchecked instead of rounding them up into the evidence. Never place credentials, keys, or personal data in a handover: record that access was transferred, not the secret itself. The acceptance is a decision record, not a warranty or a payment, and a receipt proves the saved result was not changed, never that the software was correct. The client still judges the build. The record settles which build they judged.

Frequently asked questions

What is a developer client handover?

A developer client handover is how a developer delivers finished software as one link: the acceptance criteria, the build delivered identified precisely, the test and check results for that build, the deploy step, the access and documentation items, the known issues, and a verifiable receipt for each recorded step. The client opens the link with no account, checks the evidence, and accepts the delivery or flags one step. It replaces the it is live email and the demo call.

How should known issues be handled in a developer handover?

List them in the open items, in plain words, before the client accepts. Acceptance then means the client accepted this version with those issues known and recorded, which protects the developer when an issue is later reported as if it were a surprise, and protects the client because the list is fixed in the record the developer sent. Issues discovered after acceptance are new items for the support conversation, measured against the delivered record as the baseline.

Can a client check the test evidence in a handover themselves?

Yes. Each recorded step carries its receipt, and anyone can check a receipt free at https://zambo.dev/verify/ with no signup: the check confirms the saved result was not changed after the fact. That does not prove the tests were sufficient or the code correct, and a good packet does not claim it does. It proves the evidence the client is looking at is the evidence produced when the work ran, which is what makes remote acceptance reasonable.

What should never go into a developer handover packet?

Never put credentials, API keys, passwords, or personal data in the packet. Record that an access item was transferred and let the client confirm it, but move the secret itself through a proper secrets channel, or hand it over in the client's own systems. Redact keys and addresses that appear in logs or transcripts before publishing. The packet should be complete about the delivery and contain nothing whose exposure would harm the client or the developer.

How much does a developer client handover cost?

Public handovers are free to send and free for the client to open. For $0.99, a Day Pass covers 24 hours of recorded work through the Zambo MCP at https://zambo.dev/mcp, which runs 153 tools in total with 35 on the default surface. Ongoing use is the Zambo Pass at $29 a month or $290 a year, and $19 a month for $ZAMBO holders. Humans pay by PayPal or card through PayPal; agents pay USDC on Base through x402.