When a supplier says you own the software, ask which of four things they mean, because they are separable and the difference decides whether you can ever leave.
One: the intellectual property
This is the agreement governing rights in the work. Do not infer an assignment from payment or access to a repository. Have the written terms reviewed for the applicable jurisdiction and the actual parties creating the software, including any subcontracting arrangements.
A licence can be perpetual and broad and still leave you unable to sell the business with the software included, sub licence it, or use it in a way the licence did not anticipate. Ask for assignment, in writing, effective at delivery.
Watch for carve outs. A supplier may assign the work produced for you while retaining rights in pre existing frameworks and libraries it reused. That can be reasonable if the retained components are genuinely generic and licensed to you perpetually. It is not reasonable if the retained component is the core of the system.
Two: the source code
Access to the code, in a repository you control, at the latest version, including the history.
The history matters more than people expect. A repository handed over as a single commit called "initial delivery" throws away the record of why decisions were made, which is the thing a new engineer needs most.
Check what is excluded. Build scripts, infrastructure configuration, database migrations, seed data and test suites are all part of the system. A delivery that includes application code and excludes the deployment configuration is not a delivery.
Three: the accounts and infrastructure
This is the one most often overlooked and the one that most effectively locks you in.
If the domain is registered to the supplier, the hosting account is theirs, the database is inside their organisation and the third party service keys are in their name, then you own code you cannot run. Changing supplier becomes a migration project rather than an access change.
Every account should be registered to your organisation from the start, with the supplier holding access to it rather than owning it. That is not an unusual request and a supplier who resists it is telling you something.
Four: the documentation
Code without documentation is technically yours and practically not.
What you need is an architecture description explaining how the parts fit together and why, a schema reference, a deployment guide written for someone who was not on the project, a runbook covering deploy, rollback, restore, key rotation and the likely failures, an environment variable reference, and a list of third party dependencies with their licences.
The test of whether documentation is adequate is simple: could a competent engineer who has never seen the system deploy it from a clean environment using only the documents? If nobody has tried, assume the answer is no.
The questions to ask before signing
Put these in the procurement conversation rather than the closing one.
Will the intellectual property be assigned to us at delivery, and is that in the contract? What exactly is excluded from the assignment, and under what licence do we hold it? Will the repository include full history? Will every account be registered to our organisation? What documentation is delivered, and will you perform a handover walkthrough? If we chose another supplier in two years, what would they need from you, and would they get it?
That last question is the useful one. A supplier confident in their work answers it directly.
Why it matters even when the relationship is good
The point of ownership is not distrust. It is that circumstances change: a supplier is acquired, changes direction, raises prices, or loses the person who knew your system. None of those are hostile and all of them leave you exposed if you do not hold the four things above.
Sawhorse delivers complete source code and documentation, assigns the delivered IP to the client and retains no ownership of that delivered code or IP. Put the account and access arrangements into the delivery plan as well, so the handover covers operation as well as ownership.
Distinguish delivered work from its dependencies
A custom application can include open source packages, fonts and services operated by other vendors. Owning the custom work does not mean owning those vendors' products or cancelling their licence conditions. WIPO's copyright licensing overview explains that open source licensing remains an exercise of copyright, not its abandonment. Ask for a dependency inventory that identifies what is included in the repository, what is loaded at runtime and what is called as an external service.
For each external service, record whether the application can export its data and what would be needed to replace it. A generated document stored only in a supplier's account is a different problem from a library whose source and licence are already included in the repository. The inventory should help the client identify that difference without reading every import.
Separate legal review from a practical exit test. A lawyer can review the rights and restrictions; an engineer can verify that the delivered system builds and runs with client controlled access. Neither exercise substitutes for the other.
Before ending the engagement, try a routine change using the delivered materials. Update a configuration value in a separate environment, run the tests and deploy the result. If that requires an undocumented account or a file outside the repository, record the missing dependency and resolve it. Ownership becomes operationally useful when another authorised team can maintain the product without guessing what the original supplier kept elsewhere.