I run a dev shop. How do I put proof on every client build update?
Build the update from the job record instead of writing it: each update ships as a handover whose steps are the work items completed, whose test steps carry their actual results, and whose open items are named. The client reads the update in the same object they later accept, so proof is the format, not an attachment.
Dev shop updates decay into literature: a weekly email describing progress in adjectives, while the client privately wonders what "nearly done" costs. The record-based update replaces adjectives with the job's own trail. Work items are steps; their saved results are the evidence; test runs are steps whose outputs sit on the record instead of being summarised as "all passing."
The cadence makes it sustainable. Developers and agents already produce the steps by doing the work through the connection; the update is assembled by selecting the period's jobs and letting the handovers carry the detail. The human writing shrinks to the parts clients actually need from a human: what changed for them, what is blocked and on whom, what decision is needed and by when.
Client sign-off closes the loop the same way as any delivery in this file: the decision recorded on the update record, dated, against the exact steps it covers. Over a long engagement those recorded updates become the project's spine: a new stakeholder can read the whole build history as accepted records instead of inheriting a mailbox.
Template: the build update record
Per update: 1. Jobs covered, one line each with their handover links. 2. Steps completed in the period, grouped by job, results openable. 3. Test steps: suites run, results as saved, failures named with their fix steps. 4. Open items: blocked steps with the blocker named (ours, theirs, third party). 5. Decision needed: one item, one owner, one date. 6. Client sign-off recorded on the update record. Assembly rule: if a claim in the update has no step behind it, it leaves the update.
Worked example
One update's job in public shape: https://zambo.dev/handover/bd7e5325-33fd-4c5e-b029-76b781fa2f51 shows five steps with their state visible, the pattern a client reads weekly. A quarter of updates in this shape is a build history no status meeting can misremember.
Frequently asked questions
Our clients get GitHub or GitLab links already. What does the record add?
The code's history, which repositories give you, is half the story. The record adds the work around the code: the investigation, the checks, the decisions, and the client's own sign-offs, in the order a non-developer stakeholder can follow.
Will developers accept another reporting duty?
The update is assembled from steps the work already produced, which is the opposite of another reporting duty. The shops that adopt it report the weekly update email dying within a month, which developers experience as a gift.
How granular should steps be for build work?
One step per meaningful work item or check: a feature slice, a fix, a test run, a deployment. Finer than that becomes noise; coarser becomes the old summary with links attached.
By Brennan Zambo, founder of Zambo.
Last verified: 2026-10-17.
Try a handover
A handover gives your client one proof link with verifiable receipts to review, then Accept or Flag.
try it: say 'use zambo to hand this over to <client>' in your ai