Staging-first approval
Sign-off happens on the running product, and the record ties to what was reviewed.
Use case · Freelance developers
Merge to main. Hand over on your terms.
Client approves against staging, the repository export and credentials sit locked, and the moment the final payment is confirmed the whole package unlocks — hashed, logged, and certificated.
“Just push it to our repo and we'll sort the invoice”
For developers, handover is uniquely irreversible: once the code is in the client's repository or the credentials are in their inbox, the work is delivered in full. Chasing the final 40% afterward is charity. And months later, “the site broke” arguments need evidence of exactly what was delivered and approved — which a chat thread will not give you.
Who this is for
- Freelance web and app developers
- Contractors delivering source at project end
- Developers handing over deployment credentials and infra docs
- Agencies subcontracting build work with staged payments
How it works
- 1
Scope and milestones, signed
Features, environments, maintenance boundaries, and the payment schedule in a signed agreement.
- 2
Approve against staging
The staging URL is the preview. The client clicks through and signs off — recorded against that review.
- 3
Lock the delivery package
Repo export, env documentation, credentials, and runbooks are payment-gated deliverables with SHA-256 hashes.
- 4
Unlock, log, certificate
Confirm payment; the package unlocks, the download is logged, and the certificate records the delivered hashes.
Hash-proof source delivery
The delivered archive's SHA-256 hash is on the certificate — what you shipped is provable byte-for-byte.
Credentials with the package
Secrets and access docs are part of the locked handover, not scattered across messages before payment.
Maintenance boundary
The certificate closes the build scope; support and maintenance start as their own agreed work.
Frequently asked questions
How does source code handover actually work?
Export the repository (with docs and env notes) as an archive deliverable. It stays locked until payment; on unlock, the client downloads it and the event plus hash are recorded.
What about projects delivered straight into the client's repo?
Use milestone payments gated on staging approvals, and keep final credentials/docs as the payment-gated package. You keep a delivery gate even when code review happens in their repo.
Is it safe to put credentials in a deliverable?
Deliverables sit in private, scanned storage behind revocable token access — materially safer than credentials in email or chat. Rotate secrets at handover as usual.
How do I prove what version I delivered?
The SHA-256 hash on the certificate matches the archive you delivered. If the client's copy hashes the same, it is the same code.
Send your first handover link in minutes
Free plan includes one full handover — approval link, payment-gated files, and a proof certificate.
Create your free account