Software Ownership: Nine Assets, Three Moments

You own your software when you can answer nine questions and point to where each answer lives.

The nine answers are source code, repository, hosting, domains, accounts, data, documentation, backups, and dependencies. Most disputes Garaxe hears about ownership are not about one missing answer - they are about three, discovered the week a relationship ends. The matrix below makes each answer explicit at the moment it is cheapest to secure: contract, build, or handover. It is not legal advice; it is a custody test.

The nine-asset matrix

Self-contained. Each row is secured at one of the three moments; the test is whether you can answer the row today without asking the vendor.

Asset	What “owned” means in practice	When to secure it	How to verify
Source code	You have the code as it runs, not a zip from six months ago	Contract + handover	You can open the repository that the running build was built from
Repository	You control the repo - owner or organization admin, not guest	Contract	You can add a second admin who is not the vendor
Hosting	You control the account that runs the code - or the vendor account is explicitly transferable	Contract	You can log into the hosting console with your own identity
Domains and DNS	You own the domain and the DNS zone	Contract	You can change a DNS record without the vendor
External accounts and keys	API keys, email, storage, and third-party services are in accounts you control	Build	No key lives only in a developer’s personal account
Data	You have the data, its shape documented, and an export you have tested	Build + handover	You have performed a real export and opened it
Documentation	How it works, how it deploys, and how it fails is written where the next person will look	Build	A new developer can deploy a trivial change guided only by the docs
Backups	Automated, tested, and restorable without the vendor’s help	Build	You have restored to a staging environment
Dependencies	Third-party costs, licences, and what breaks if each vendor changes	Contract + build	Each dependency has a named owner, cost, and replacement note

The cheapest moment for the first three rows is at signing. At handover they cost a negotiation; during a dispute they cost a project.

What already exists - and where it stops

Handover checklists for small businesses are not rare, and it would be dishonest to write this as though nobody had covered it. Of the pages we opened on 24 August 2026, one publishes a twelve-item handover checklist for SMEs with a “how to verify it” column against every row - company-controlled account can clone and build the code, restore a database copy in a non-production environment, a new person can follow the deployment steps. Another sets out four asset classes and a ten-point scorecard. A third gives a set of pre-signing questions and a process for auditing software you already have. If you only ever read one of those and worked through it, you would be ahead of most owner-operated businesses.

Two things they consistently do not do, and both of them are the difference between a list and a decision.

They do not say when. The strongest checklist we read mentions “before final payment” and offers a seven-day handover plan, but does not separate what you must demand in the contract from what has to be captured while the software is being built from what can only be verified at handover. The four-class page is heavier still on contract language and thinner on the build. Read as a single list at the end of a project, a checklist arrives after the moment when most of its items were cheap.

They do not price the gap. Every item is presented as equally important. In practice they are not remotely equal: a missing DNS record is an afternoon, and a database whose shape nobody documented is a rebuild. Nothing we read tells an owner which missing item is an inconvenience and which is an emergency.

This guide is the same inventory, organised by those two questions.

What each missing asset actually costs you

The point of knowing when to secure something is knowing what it costs when you did not. These are our estimates of severity at switching time, not measured figures, and they assume the relationship has ended without goodwill.

Missing asset	What it costs at switching time	Severity
Domains and DNS	Hours, if the registrar account is recoverable. Days and lost email if it is in a personal account nobody can access	Low to severe, depending entirely on whose name it is in
Repository access	Days. The code usually exists somewhere; the argument is about who hands it over	Moderate
Hosting account	Days to weeks. You may be able to redeploy, but not while the running system is on an invoice you do not pay	Moderate to high
Source code as it runs	Weeks. A six-month-old zip is not the running system; the gap between them is undocumented work	High
External accounts and keys	Days, plus quiet breakage. Integrations fail one at a time over the following month as keys are rotated or expire	Moderate, and deceptive - it looks fine at first
Documentation	Weeks of a new developer reading code to rebuild knowledge that already existed	High
Backups you have never restored	Unknown until you need it, which is the problem. A backup that has never been restored is a belief, not an asset	Severe
Data with an undocumented shape	Months, or a rebuild. This is the one that ends projects	Severe
Dependencies and licences	Variable. Usually a surprise invoice or a service that stops when a card expires	Moderate

Read that column and the ordering changes. Most owners chase the source code first because it feels like the thing they bought. The two rows that actually end projects are the untested backup and the undocumented data shape, and both are secured during the build, not at handover.

The three models - and why the sentence matters more than the price

SWF Consultancy’s 2026 framing is useful because it makes the sentence explicit. Model one - developer retains IP, client receives a licence to use, often tied to continued payment - is more common than most clients realise, particularly with agencies. Model two - client owns the executable, not the source - is a step better but still leaves you unable to modify, fix, or develop further without returning to the original developer. Model three - full assignment on final payment, source and schemas and build scripts transferred, code in a client-owned repository from day one - is genuine ownership. The price of the bespoke project can be identical under all three models; the sentence in the contract is the difference between an asset and a dependency.

That is why the nine-asset test exists. A contract that says “full assignment” but leaves the repository as a guest account, the hosting on a developer’s personal card, and the data shape undocumented still fails the custody test on six of nine rows. Conversely, a contract that says “licence” with the source in your own organization from day one and transparent commits can be more takeover-able in practice than a “full assignment” clause whose code you cannot locate. Garaxe’s default is model three plus the custody inventory: the legal sentence and the operational answers together.

The SaaS question is separate and worth naming explicitly because many owner-operated businesses conflate it. With SaaS - CRM, ERP, inventory, project management - you own nothing. You are renting access to software running on someone else’s servers, storing your data in their database, on terms that can change. That is not necessarily wrong; lower upfront cost and vendor-managed infrastructure are reasonable for general-purpose tools. The problem is unexamined dependency: core operational processes built around a SaaS product with no export capability and no alternative have no negotiating position when the vendor raises prices, is acquired, or deprecates an API.

Why this matters more for owner-operated businesses than for companies with IT teams

A company with an IT team has institutional custody - accounts, repositories, and runbooks outlast any one vendor. An owner-operated business has personal custody. When the vendor is the repository admin, the hosting payer, and the only person who can deploy, the business is rented whether the contract says “you own the code” or not. Garaxe’s default is to invert that: every asset above lives in the client’s name or a shared organization the client admins, from the first commit. It costs nothing to set up that way at the start and a great deal to fix at the end.

The nine assets in detail - and the cheapest moment to secure each

A custody answer that costs nothing at signing costs a negotiation at handover and a project during a dispute. The table below states the asset, what “owned” means in practice, when it is cheapest to secure, and the one-line verification you can run today without the vendor.

At signing (contract) - where your position is strongest

Source code, repository, hosting, domains, and key dependencies are cheapest here because you still have alternatives. “You own the code” in a services agreement does not make an undocumented system takeover-able if the repository is a guest account, the build artifact is a dated zip, or the hosting invoice is paid by a developer’s personal card. Ask for organization admin on the repo, shared organization on hosting with your identity as an admin, domain and DNS zone in your name, and a dependency list with cost and replacement note per third party. Verify by adding a second admin who is not the vendor and by changing a DNS record without them.

Garaxe’s default is to put every one of these in the client’s name or a shared organization the client admins from the first commit - no extra cost then, material cost to fix later.

During build (the plumbing that becomes custody later)

External accounts, data, documentation, backups are created during build and are where future lock-in quietly accumulates. Keys in a developer’s personal account, data whose shape is undocumented, docs that describe how to use the system but not how to deploy it, backups that have never been restored - each is an asset that only shows up as a problem when the relationship ends. During build, verify that no key lives only in a personal account, that a real data export has been opened and read, that a new developer can deploy a trivial change guided only by the docs, and that a restore to staging has actually been run.

At handover (prove it)

Source code as it runs, data, documentation, backups are proved here. Handover is not a zip and a call - it is the moment the nine answers are demonstrated. The running build must be traceable to the repository you control; the data export must be shape-documented; the deployment must be runnable by a second person. If that demonstration fails, handover hasn’t happened, whatever the contract says.

How to verify any of this without being technical

Every published checklist we read, including the good one, assumes a reader who can clone a repository and restore a database. Most owners commissioning software cannot, and should not have to. The verification that matters is not performing the technical step yourself - it is asking for a demonstration and knowing what a good answer looks like.

Ask the person who built it to show you, on a call, while you watch:

• “Add my colleague as an admin on the repository.” A good answer does it in under a minute. A bad answer explains why that is complicated.
• “Log into the hosting account using my identity, not yours.” A good answer already has that set up. A bad answer needs to “get back to you.”
• “Export the data and open it in front of me.” A good answer produces a file whose columns make sense when read aloud. A bad answer produces something that needs interpretation.
• “Restore last night’s backup into a test environment.” A good answer has done it before. A bad answer has never tried, which is the same as not having backups.
• “Have someone who has not worked on this deploy a trivial change using only the written instructions.” This is the single most revealing request on the list, and the one most likely to be resisted.

You are not auditing the technology. You are watching whether the demonstration is routine or improvised, and the difference is legible to anyone. Resistance to any of these is information, and it is cheaper to collect while you are still paying invoices.

A note on the legal sentence

This guide covers practical custody and switchability - where things live and who can change them. It has three limitations worth stating plainly. It is not legal advice, and the custody test passing tells you nothing about whether your contract assigns the intellectual property. The severity ratings are our practitioner judgement rather than measured figures, so treat them as an ordering, not a quantity. And the whole inventory assumes bespoke software built for you; if you are renting a SaaS product, most of these rows do not apply and the real risk is data export, which behaves differently. Intellectual-property assignment (“who owns the work for hire”) needs your own legal advice. The custody inventory here does not replace that advice; it makes the conversation concrete. Bring the nine answers to that conversation and the lawyer’s question becomes specific.

What to check in your current arrangements - this afternoon, not someday

If you already have bespoke software - from an agency, a freelancer, or an in-house developer who has since left - three checks settle the question quickly. First, find the contract and search for “intellectual property,” “IP assignment,” “source code,” and “licence.” If it says “licence to use” and nothing about assignment, assume you do not own the software in any meaningful sense. Second, establish where the source code is. If it lives only on the developer’s systems and you do not have a copy in an organization you administer, you are dependent on goodwill. Request access - resistance tells you something important about how the relationship is viewed. Third, check whether the code is documented and readable. Owned source you cannot understand has limited value; a well-structured codebase with sensible naming can be handed to any competent developer, while undocumented workarounds cannot.

Those three checks take an afternoon. They are worth doing before the moment you need to change something and discover the cost.

FAQ

A vendor said “you own the software.” Is that enough? No. Ownership is nine custody questions, not one sentence. You need to be able to point to where the code, repository, hosting, domains, accounts, data, documentation, backups, and dependencies live - and who can change each on any given day.

We already signed - can we fix this afterwards? Some assets can be fixed later (repository access, hosting accounts), but the cheapest moment is at signing. A handover without the repository or deployment path is a handover you cannot use.

Does hosting matter if we own the code? Yes. Code without a deployment you control is code you cannot run. Ownership includes who can deploy, who pays the hosting invoice, and what happens when that invoice stops.

What about source-code escrow - do we need it? Escrow is a specialist arrangement with its own trade-offs, and it is a different question from custody: escrow is about what happens if a vendor fails, whereas everything above is about what you control while the relationship is healthy. Our exit-plan guide covers it properly; if the nine answers above are already in your name, escrow solves less than it appears to.

Is this legal advice? No. This guide covers practical custody and switchability. Intellectual-property assignment needs your own legal advice; the custody inventory here makes that conversation concrete.

Notes

• Live result set retrieved 2026-08-24 (en, GB proxy) via requests req_f0c4727250f4 and req_e78f371af63e, both at zero budget; three pages opened and read in full. See research/live-result-set.md.
• The published set contains both an IP-law cluster and a substantial set of operational handover checklists - at least six across the two result sets. What none of the pages we opened does is map assets to the moment each must be secured, or state what a missing one costs. That mapping is this page’s contribution.
• The nine-asset inventory, the timing map and the severity column are Garaxe’s practitioner framing, described as we genuinely use them. The severity column is our judgement, not a measured figure, and no client outcome or success rate is claimed anywhere on this page.
• This is not legal advice. IP assignment, licence scope and contract drafting need a solicitor.
• No AI-assistant answer baseline was collected: the probe was unavailable on 2026-08-24. Nothing here is a claim about what an assistant answers for this question.
• Autocomplete returned no suggestions and no People-Also-Ask questions were returned, so this page makes no claim about what owners search for.