Ownership is the least discussed and most consequential difference between licensing a platform and having software built for your company. It rarely comes up in evaluation, because in year one it changes nothing. By year five it can be the single largest factor in what your operations cost and what options you have.
This article covers what ownership actually means in practice, how it changes long-term economics, what happens when you part ways with a vendor, and the specific contract terms that determine whether you own anything at all.
What you're paying for in each model
With a platform, you're buying access. The vendor owns the software, hosts it, decides the roadmap, and grants you a licence for as long as you keep paying. Your configuration, custom objects and workflows are assets that exist only inside their product. Your data is yours — usually exportable as CSV — but the logic that makes the data useful is not.
With a custom build done properly, you're buying an asset. You own the source code, the schema, the deployment configuration and the documentation. It runs on infrastructure in your name. If the company that built it disappears, you still have a functioning system and the means to have someone else maintain it.
That distinction only holds if the contract says so — which is why the terms below matter more than any assurance in a sales call.
What genuine ownership includes
Ask for these explicitly. A vendor who builds this way will hand them over without hesitation:
- Full source code in a repository your company owns, with complete commit history.
- The database schema and migration scripts, plus a documented backup and restore procedure.
- Infrastructure and deployment configuration, with cloud accounts registered to your business and billed to you directly.
- Documentation sufficient for a competent engineering team to take over — architecture overview, environment setup, deployment steps, key business rules.
- Written confirmation that no part of the system is shared with other clients or dependent on the vendor's proprietary internal framework.
- Clear ownership of any third-party API keys, domains and service accounts.
The ten-year economics
Platform costs are recurring and headcount-linked. A team of 40 on a mid-tier CRM plus a field service module, an integration platform and an implementation retainer can comfortably reach $8,000–$15,000 a month. Over ten years, at typical price increases and modest growth, that's well past seven figures — and at the end of it you own nothing and can't stop paying without losing the system.
A custom build is front-loaded: a one-time engineering investment, then hosting (often a few hundred dollars a month) and a maintenance arrangement sized to how much change you want. The curve flattens. Crucially, it doesn't rise when you hire, because there's no per-seat meter on your own staff.
The crossover point varies by team size and complexity, but for service businesses at scale it typically lands somewhere in years two to four. Everything after that is retained margin. This is the same arithmetic we walk through when weighing custom against platform customization.
What actually happens if you switch vendors
This is the real test of ownership, and the honest answer is that it depends entirely on what you hold.
If you own the repository, schema, infrastructure and documentation, switching is a normal transition: a new team clones the code, spins up environments, spends a few weeks reading, and continues. Not painless, but bounded and predictable — the same as replacing any in-house engineer.
If you don't, you're not switching vendors, you're starting over. Rebuilding from scratch, migrating data out of a system whose logic you can't inspect, and running two systems in parallel through the transition. Vendors who host the code in their own accounts, build on a proprietary internal framework, or share a codebase across clients are selling you a dependency and calling it custom software.
There's a middle case worth naming: platform-based builds. If your logic lives in Salesforce or a no-code tool, you can change implementation partners but you can never leave the platform without a rebuild. That's a real form of lock-in even though nothing looks proprietary.
The strategic dimension nobody prices
Ownership also determines who controls your roadmap. On a platform, features you depend on can be repriced, deprecated or moved to a higher tier, and you have no recourse beyond migrating. Companies have been forced into six-figure re-implementations by a vendor's packaging decision.
Owning the system means the roadmap is yours. It also means the software is an asset on your side of the ledger — one that acquirers and lenders can evaluate, and one that encodes operational advantage competitors can't buy off a shelf because it isn't for sale.
One honest caveat
Ownership carries responsibility. You own the maintenance, the dependency updates, the security patching and the hosting. With a platform, someone else does that and it's genuinely worth something.
In practice this is handled by a maintenance arrangement, and it should be optional rather than a disguised licence. The test is simple: if you stopped paying for maintenance tomorrow, would the system keep running? With real ownership, yes — you'd just stop receiving updates. If the answer is no, you're renting.
The short version
- Ownership means source code, schema, infrastructure and documentation in your name — not just the ability to export your data.
- Platform costs recur and scale with headcount; owned systems front-load the cost and flatten, typically crossing over in years two to four.
- The switching test decides everything: with real ownership, changing vendors is a transition; without it, it's a rebuild.