Build the capability. Keep control of what belongs to you.
An engineering engagement should not end in a black box. The client needs a clear record of what was created, what they own, what remains licensed and what it takes to operate or extend the system.
Could another team take over without guesswork?
Source transfer is only part of control. Agree what is assigned, what remains licensed, where access lives and how a new engineer will prove the system can be built, deployed and operated.
Ownership and operability are two different questions.
Ownership
What do the contract and third-party licenses permit you to own, use, change and transfer?
Operation
Can the people responsible obtain access, reproduce the build, deploy safely and respond to a failure?
Custom deliverables
Define assignment and source-transfer boundaries in the contract. The agreed scope determines what is delivered and what rights transfer.
- Record the boundary
- Statement of work, deliverable inventory and agreed repositories.
Licensed components
External services, platforms and packages retain their own terms. Commissioning a system does not transfer ownership of those products.
- Record the boundary
- Dependency and licensing register, including accounts and usage obligations.
Operating access
Agree who controls repositories, environments, credentials and administration. Record the process for granting and revoking access.
- Record the boundary
- Access-role map, environment inventory and deployment instructions.
Ongoing responsibility
Make maintenance, incidents and optional support explicit. A handover should not leave responsibility implied.
- Record the boundary
- Runbooks, known limitations, maintenance owner and any agreed support scope.
A dependency can be legitimate. It should be legible.
A useful register makes each subscription, platform and license explicit. Portability means knowing the replacement boundary; it does not mean every component is interchangeable.
- Model or external API
- Control to recordAccount owner, approved terms, data settings and usage exposure.
- Portability to explainRecord the integration boundary and the assumptions a replacement must satisfy.
- Cloud or licensed platform
- Control to recordTenant ownership, environments, administrative roles and commercial obligations.
- Portability to explainDocument configuration, deployment and data export; name platform-specific behavior.
- Packages and tooling
- Control to recordVersions, licenses, build requirements and required paid access.
- Portability to explainKeep reproducible build instructions and explain any restricted dependencies.
The handover test is a rehearsal, not a file transfer.
Ask another engineer or the client team to work from the agreed documentation. Record the gaps they find, then assign and resolve them before calling the handover complete.
Start from the documented source
Locate the repository, install the required tooling and identify configuration without hidden instructions.
Build and run the tests
Reproduce the build, understand the acceptance cases and distinguish a known limitation from a regression.
Deploy into the agreed environment
Follow the access and release procedure, including the documented rollback path.
Walk through an operating failure
Find the relevant signal, follow the runbook and identify the person responsible for the next action.
The full argument for client control
For CTO, CIO, CPO, COO
The situation behind the request
A company commissions a custom internal application. It expects its developers to maintain and extend it using their own tools. The build used third-party model APIs, a cloud provider, commercial packages and generated code.
Where the obvious solution falls short
“You own everything” is often inaccurate. Bespoke source and assigned IP may be owned under contract, but external services and licensed components remain governed by their own terms. Access to source without deployment documentation is incomplete handover.
How we would approach the work
Define ownership in the statement of work, maintain a dependency register, use agreed repositories and establish delivery artifacts. Include architecture, local/deployment instructions, access roles, tests, known limitations and operating runbooks.
What the engagement may include
- Clear IP assignment boundaries for custom deliverables.
- Client-repository/source transfer where contracted.
- Architecture, test, deployment and operational documentation.
- Third-party licensing, cloud and usage register; optional support scope.
The choices worth making explicitly
Some projects legitimately depend on Salesforce, Azure or other licensed platforms. Ownership should not be confused with avoiding all subscriptions. The goal is to make dependencies explicit and controllable.
What we would test before calling it ready
Verify handover using a second engineer or client team member who can build and deploy from the documents. Record gaps and responsibilities for maintenance.
A sensible first step
Discuss the desired ownership and operating model at the architecture stage, not after deployment.