Who owns the code and business data in a custom system?

Straight answer up front. Then the details.

The short answer

It depends on your agreement — and that is the honest answer, not a dodge. Ownership of custom software is not one thing you either have or don’t. Business data, source code, the repository, hosting, the domain, API credentials, third-party accounts and documentation are each controlled separately, and each can be assigned differently in a contract.

So the useful question isn’t “do I own it?” It’s “which of these do I control, in writing, and what happens to each one if we stop working together?” Below is the full stack and a checklist you can take into the meeting.

Why one word causes so much trouble

A contractor asks “will I own it?” and hears “yes.” Both people leave satisfied and mean different things. The builder may mean you own your business data. The contractor may assume they own the code, the accounts, the hosting and the right to hand everything to someone else tomorrow. Neither of them wrote it down.

That gap is where dependence lives. Not usually through bad intent — through silence. Every layer below has a default that quietly applies when nobody names it.

The ownership stack

Nine layers, from the one that matters most to your business down to the one people remember last. For each: what it is, what should be agreed, and what creates dependence when it isn’t.

What ownership actually consists of

Your business dataOwner: The layer with the least excuse for ambiguityYour customers, jobs, estimates, invoices and history. This is your business recorded — it should be unambiguously yours in writing. Dependence risk: an agreement that is silent on data, or a system where 'export' means a PDF.
Admin accessOwner: Should be yours from day oneAn administrator account in your name, in the live system, that can manage users and permissions without asking anyone. Dependence risk: the builder holds the only admin account and you request changes through them.
ExportabilityOwner: Prove it, don't promise itGetting your data OUT in a usable structured format — and having actually run that export once, before you need it. Dependence risk: an export that technically exists but produces something no other system can read.
Source codeOwner: Contract-specific — name it explicitlyThe instructions the system is built from. Rights depend on the agreement: assignment, work-for-hire language where applicable, or a license. Dependence risk: assuming ownership transferred because nobody said otherwise.
RepositoryOwner: Where the code actually livesOwning code and being able to reach it are different things. A repository account in your organization's name, with the history in it, is what makes the code usable by someone else. Dependence risk: code that exists only on the builder's machine or personal account.
Hosting and databaseOwner: The account matters as much as the softwareThe infrastructure the system runs on and where the data physically lives. Dependence risk: hosting billed to the builder's account, so you cannot see, pay for or move your own system without their cooperation.
Domain and DNSOwner: Small layer, large consequencesThe address your team and customers use. Registered in your name, with you on the account. Dependence risk: the smallest thing on this list and the one most likely to hold a business hostage during a bad separation.
Third-party services and credentialsOwner: Usually the messiest layerEmail/SMS providers, payment processing, mapping, storage, accounting API credentials. Accounts in your business name and billed to you, with the builder holding access — not the reverse. Dependence risk: services in the builder's name that stop when the relationship does.
Documentation and transition rightsOwner: What makes every layer above usableHow it's deployed, what it depends on, how integrations are configured, what's known to be fragile — plus what the agreement says happens at the end. Dependence risk: full legal ownership of a system nobody else can understand well enough to take over.

Read the bottom layer twice. Legal ownership without documentation and access is a certificate, not control. Most real dependence isn’t created by a contract clause — it’s created by knowledge that only lives in one person’s head.

Licensed components: the honest footnote

Essentially all modern software is built partly on existing components — frameworks, libraries, platform services. You can own the custom work built for your business without owning those underlying pieces, which come with their own licenses and terms. That is normal and not a problem, but it should be visible rather than discovered later.

Worth naming in the agreement:

Which parts are custom work built for your business
Which parts are third-party or open-source components, and under what licenses
Whether the builder is reusing anything of their own, and on what terms you may use it
Whether any component carries recurring cost or usage limits
Whether anything would prevent another developer from continuing the work

Before you sign, ask these

Print this. Bring it to the meeting — with us, or with any developer. A builder who answers these clearly and in writing is telling you something about how the relationship will go. One who gets uncomfortable is telling you something too.

The ownership contract checklist

Who owns the business data — stated explicitly, not implied?
Can I export it, and may I run that export myself, whenever I want?
What format does the export produce, and could another system actually use it?
Who owns the repository account, and is it in my business's name?
Do I receive repository access during the project, or only at the end?
Who owns the custom source code, and by what mechanism — assignment, license, other?
What third-party or licensed components are involved, and under what terms?
Who controls hosting, and whose payment method is the account billed to?
Who controls the database, and where does the data physically live?
Who controls the domain and DNS?
Who controls API credentials and integration connections?
Which third-party service accounts exist, and in whose name?
Which recurring services are genuinely required to keep the system running?
Who pays ongoing infrastructure costs, and what is the expected range?
What documentation will exist at handover, and may I see an example?
Could another qualified developer take this over from the documentation alone?
What happens to every account and credential if we stop working together?
Are there transition obligations — and is there a defined timeframe for them?
Is there anything in the agreement that limits my ability to hire someone else?

This is operational guidance, not legal advice. Ownership and intellectual-property rights are determined by the actual agreement, applicable licensing and how the system is built — have an attorney review anything consequential before you sign it.

What ownership does and doesn’t mean

We say you should own the system that runs your business. We should be equally clear about what that sentence does not mean, because a promise of zero dependence would be a lie.

Ownership means:

Clear rights — written down before the build, not negotiated after
Clear access — accounts and credentials in your name
Clear costs — you know what runs monthly and why
Clear responsibilities — who maintains what, defined
A clear exit — another qualified builder could take over

Ownership does NOT mean:

No monthly costs — hosting and services are real and ongoing
No third-party dependencies — every system has them
No maintenance — software needs upkeep or it decays
No future work — your business will change and so should the system
That you'll never need a developer again

Ownership is not the absence of infrastructure. It’s control, transparency and portability where architecture reasonably allows — knowing what you depend on, why, what it costs, who controls it, and what happens if we are no longer involved.

Portability: three different things

“Portable” gets used as one word for three separate capabilities, and conflating them is how people end up surprised.

Most achievable

Data portability

Getting your records out in a structured, usable format
Reasonable to expect and simple to verify — run the export
The single most important portability guarantee to secure

Depends on rights and access

Code portability

Another developer can read, run and continue the work
Requires rights, repository access AND documentation together
Code you own but cannot hand to anyone is not portable

Most constrained — be honest about it

Infrastructure portability

Moving the running system to different hosting or services
Always bounded by the platforms, APIs and databases it was built on
Anyone promising instant relocation anywhere is overselling

You can genuinely own your code and still depend on cloud services, APIs, databases, frameworks and platform vendors. That’s true of every modern system, including ours. The goal isn’t zero dependence — it’s dependence you chose, understand and could unwind if you had to.

ACS guidance — written from operator experience building systems for contractors, not from vendor marketing. Last reviewed August 10, 2026.

Reviewed by Connor Adler, Adler Custom Systems

ACS guidance on operational ownership, access and transition. Intellectual-property and contract questions are jurisdiction- and agreement-specific and are not addressed here as legal conclusions; no ACS contractual terms are stated or implied on this page. Have an attorney review any agreement before signing.

The thing underneath it

You built the business.
You should own the system that runs it.
Clear rights. Clear access. Clear costs. A clear exit.

Our approach

We design systems around your business.

Built from inside the operation—not from the sidelines. The people doing the work help shape the system.

Listen
Map
Build
Test
Refine

Worked with Connor

He Helped Me Believe

Robert shares how working with Connor helped him believe in himself, gain clarity around his purpose and begin turning his mission into something real.

Watch Robert’s story

Where to go from here

Review ownership terms

Start with what your operation actually needs to own. The audit maps how your work moves and what a system would have to control — bring the checklist above to any builder you talk to, including us.

Review Ownership Terms

About two minutes
No sales call required