What client ownership means in practice

Every agency website says you will own your software. Almost none of them says what that means at the account level, which is where ownership actually lives. We have taken over enough projects to have seen the other version up close: a business that paid for a product in full and controls none of the doors to it. The code sits in the developer's personal account, the servers bill to a card nobody can find, the domain renews under an email that stopped answering. Nobody planned that hostage situation. It assembled itself, one convenient shortcut at a time. Here is the setup that prevents it, in enough detail to check your own project against.

The walk-away test

Ownership has one honest test. If you fired your developer this afternoon, with no notice and no goodwill, what still works tomorrow? Can a new team get the code, deploy it, read the documentation, and carry on? If the answer involves the old developer doing you a favor, you do not own the product. You rent access to it, and the rent is denominated in goodwill, which is a currency with a famously unstable exchange rate.

The four things, one by one

Code means the repository lives in an organization account that belongs to your company, under your billing and your admin rights, from the first week, with the developers invited in as collaborators. Invited is the load-bearing word. You add us. You can remove us. The direction of that arrow is the whole point, and moving a repository later, while possible, is exactly the kind of favor the walk-away test forbids you from needing.

Infrastructure means hosting, database, and every third-party service run in accounts registered to your company, on your payment method. It costs a few extra minutes of setup at the start. In exchange, invoices arrive addressed to you, budgets are visible to you, and access is yours to grant rather than yours to request. Data means your customers, records, and files sit in databases inside those accounts, and a documented, tested export exists, because data you cannot extract is data you are storing for someone else. And domains, the most commonly orphaned asset of all, live in your registrar account, since a lapsed domain in an ex-developer's name can switch off a healthy business overnight.

Why a vendor would set things up against itself

Fair question, since lock-in is quietly profitable. The answer is that lock-in is profitable the way a squeaky toll bridge is profitable: it collects, and everyone resents the bridge. Clients who stay because leaving is painful become clients who audit every invoice. Clients who stay because the work is good become the ones who send referrals. We would rather compete on the work. It also keeps us sharp, and we say that with the small discomfort of people who have made lock-in impossible for themselves on purpose.

Checking an existing project

So to confirm, you can audit this today without any technical skill. Open the checklist above and ask, for each line, "which account is this in, and can I log into it right now?" Anything you cannot answer is a finding. None of the fixes require drama, and a professional developer will cooperate with all of them without friction. Watch closely the reaction of one who does not. That reaction is also a finding.

Software project rescue and takeover →

Ongoing development and support →