Own the system in a way you can verify.
Software ownership has three layers: control of the accounts, rights to the project work and permission to keep using anything embedded in it. Check all three, together with the records and recovery process needed to operate the system after a handover.
01 / Three layers to put in writing.
Your company controls the repositories, cloud, domains, data and credentials from day one. You own project-specific code, configuration, documentation, prompts, evaluations and deployment definitions as each milestone is paid. We retain our background tools and methods, with a perpetual, transferable license to anything embedded in your system.
| Layer | What to check |
|---|---|
| Account control | Company administration, recovery and billing for code, cloud, domains and data. |
| Project-specific work | When rights to code, configuration, documentation, prompts, evaluations and deployment definitions transfer. |
| Background IP | A perpetual, transferable license to tools or components embedded in the delivered system. |
An account can be under company control before every milestone has been paid. A reusable tool can remain the provider’s property while your company has the right to keep using the embedded part. Keep those distinctions explicit.
02 / Acceptance criteria make a delivery checkable.
Acceptance criteria describe observable behavior the business and technical reviewer can verify. Use representative transactions, expected outputs and exceptions. Record who accepts the result. A milestone should not depend only on whether the code was delivered or whether it looked right in a demonstration.
03 / Key-person risk is missing operating memory.
A system can be well written and still depend on one person knowing how to release it, recover it or handle an exception. The remedy includes a current record, a secondary contact and proof that someone else can use the instructions. See the Operations Record.
04 / Technical debt needs a business consequence.
Technical debt is an accumulated compromise that makes a system harder or riskier to operate and change. Record its consequence before assigning a budget: repeated incidents, slow releases, blocked integrations or a dependency that cannot be maintained. An unfamiliar framework alone is not a business case for a rebuild.
05 / Vendor dependence is more than code possession.
A proprietary platform, export limitation, license restriction or inaccessible cloud account can limit the ability to move. Compare the cost of leaving before choosing a tool. Bought software can still be the best option when its limits are understood and acceptable.
06 / Source-code escrow does not replace operating control.
Escrow may provide a contractual way to receive source code under specified conditions. It does not by itself establish that the company can deploy the code, recover data or use third-party services. Get appropriate legal advice on the agreement and verify the operating dependencies separately.
07 / Ask for a usable exit package.
The exit package should include current code, system map, access inventory, runbooks, open issues, roadmap, vendor list, data export and transition sessions. Test that the receiving team can use it.
Read what happens if we disappear, follow the developer handover guide and check the guarantee boundaries.
Editorial review: Ego Eimi · Updated September 6, 2026 · About the team
Your technology
Start with the business
Your business depends on it.
Tell us which system matters, what has changed and who controls it. We will define a reviewable next step. Read Foundation and the commitments and evidence.