A Practical Agency Handoff Without Platform Lock-In

A practical agency handoff without platform lock-in

An agency handoff is not complete when the client receives a password. It is complete when ownership is clear, routine work no longer depends on one person and the client can keep operating—or leave—without reconstructing the application from screenshots and invoices.

The best handoffs are designed at project creation, not assembled during the final week.

Ownership is not one setting

Separate at least five forms of control:

• commercial ownership: who commissioned and owns the deliverable under the contract;
• workspace ownership: which organisation controls members, projects and billing;
• source ownership: where the canonical repository lives and who controls protected branches;
• service ownership: who controls domains, identity providers, payment accounts and external APIs; and
• operational responsibility: who responds to incidents, renewals and security updates.

Putting every account under an individual agency employee may feel convenient during delivery. It creates a predictable failure later.

Transfer roles, not shared credentials

Invite named users and assign the smallest useful role. A content publisher does not need billing access. A client approver does not need to rotate secrets. An agency engineer may need a time-bounded maintenance role after handoff rather than permanent ownership.

Shared passwords erase accountability and make revocation unreliable. Use individual identities, multi-factor authentication and an emergency-access process owned by the client.

Hand over evidence with the application

A usable handoff pack identifies:

• the repository and accepted release;
• build, preview and production commands;
• framework and runtime versions;
• domains and certificate responsibility;
• named configuration and secret bindings without secret values;
• data stores, backup expectations and retention;
• external services and renewal dates;
• current roles and pending invitations;
• rollback and incident contacts; and
• unresolved limitations accepted by the client.

Demonstrate the path. Ask a client administrator to invite a colleague, view a deployment, update approved content, locate usage and export the application. A document alone cannot prove that permissions or recovery work.

Portability needs a tested exit

“You can export at any time” is weak unless someone has exported. Verify that the client can retrieve source, ordinary static assets and application data in documented formats. Record provider-specific infrastructure separately from portable application code.

BlinkHost agency workflows keep client organisations, access grants, repository history, approvals and handoff decisions distinct. The goal is continuity: an agency can continue supporting the client without becoming an invisible root account, and the client can change the relationship without losing the product.

Keep billing explicit

Decide whether the client pays the platform directly or the agency resells a managed service. Document allowances, add-ons, support and what happens when an invoice or mandate fails. Never make production continuity depend on an employee’s personal payment method.

Close with acceptance

Use a recorded acceptance meeting. Review the live application, known limitations, access, data, billing, rollback, maintenance and exit. Capture requested changes separately from accepted scope. A calm, explicit ending protects both teams and is a stronger foundation for ongoing work.

Primary references

• OWASP Secrets Management Cheat Sheet
• NIST digital identity guidelines
• CISA Secure by Design
• GitHub: roles in an organisation

Reviewed 2 September 2026. Adapt contractual and data-protection sections to the relevant jurisdiction with qualified advice.