What “You Own the Code” Should Actually Mean

“You'll own everything” is the most common promise in custom development — and one of the most weakly delivered. Ownership isn't a sentence in a proposal. It's a set of concrete, verifiable conditions. If you're paying to build software, here's what the phrase should actually mean, in checklist form.

The real ownership checklist

• IP assignment in the contract — work-for-hire language, not a license to use your own product.
• Source code in a repository you control — your GitHub organization, your admin rights, from day one, not “on request.”
• Infrastructure in your accounts — AWS, domains, databases, and app store listings registered to your company, with the vendor as an invited collaborator, never the owner.
• Documentation that survives the relationship — architecture overview, setup instructions, and deployment runbooks a competent outside team could pick up.
• No poison dependencies — no critical component licensed personally to the vendor or priced to punish you for leaving.

The test that cuts through everything

Ask one question before signing: “If we part ways in two years, describe exactly what happens in the first week.” A partner with nothing to hide will answer in specifics — you already have the repo, here's the runbook, we schedule a handoff call. A vendor building a hostage situation will answer in vibes.

We put this checklist in our own contracts because clients who feel free to leave, stay. The retention rate proves the strategy: lock-in is what companies build when their work can't do the retaining.