What you own when you buy a custom system

Ownership is not a given

One of the toughest questions a buyer can ask a development partner is simple: "Do we own the source code from day one?"

The answer is almost always yes. But when you dig deeper, you find clauses that make "yes" mean something else. The data model is their intellectual property. Hosting may only take place on their platform. The documentation is proprietary. You own the source code, but no one else can take over without paying them a handover fee.

That is not genuine ownership. It is a formal right you cannot exercise.

What genuine ownership includes

When we talk about ownership of a custom system, we mean five concrete things. All of them should be yours, all of them should be yours from day one, and all of them should be transferable to another competent partner without friction.

1. The source code. The entire codebase, not just "the application layer". That includes infrastructure code (Terraform, Docker, deployment scripts), tests, build scripts, and everything needed to rebuild the system from scratch.

2. The data. All data in production, all backups, everything that has been logged. You should be able to export everything in a standard format at a moment's notice.

3. The infrastructure. The domain name, cloud accounts, API keys, databases. Everything should be under your legal control, registered on your company, not the vendor's.

4. The documentation. Data model descriptions, API documentation, deployment guides, runbooks for common operational problems. Should be readable and understood by people other than those who wrote the system.

5. The design and brand assets. Figma files, design system, icons, all images and videos. Not only the rendered output, but the source files.

If any of these five are not yours, or only partially yours, you do not own the system in any practical sense.

Clauses that reveal a vendor wants to lock you in

We have seen many contracts where "the client owns everything" was stated clearly, but the fine print made it an illusion. These patterns are red flags:

"The vendor has a licence to reuse the code in other projects." Fine in itself, but check whether it means they can use what they built for you for a competitor. It should be clearly delimited.

"The data model is the vendor's intellectual property." Never. The data model is the core of the system. If it is not yours, you own nothing.

"Hosting may only take place on the vendor's infrastructure." A sign that someone wants to keep you on the clock. A well-built system should be deployable to any cloud service or dedicated hardware.

"Handover to a new vendor requires 30 days of paid transfer." Fine if it means 30 days of working capacity to train the new team. Not fine if it means they can refuse handover unless you pay.

"The source code is stored in the vendor's GitHub organisation." It works in practice, but not in principle. The repository should sit under your own GitHub or GitLab. If the vendor stops paying their GitHub bill, things can become critical quickly.

"App Store and Google Play certificates are owned by the vendor." Many underestimate this. If the vendor holds the certificates, another vendor cannot update the app without rebuilding it from scratch. You should always hold the Apple Developer Program and Google Play Console accounts.

What is reasonable

Ownership does not mean the vendor should not earn money on the ongoing relationship. It is reasonable that:

• The vendor has a monthly operations and maintenance agreement for as long as you want it
• The continuation of the partnership happens because you are satisfied, not because the contract holds you back
• Handover to a new partner costs something, typically 30 to 60 hours of documented work
• Special modules the vendor has built for other clients and reused may have a separate licence

It is reasonable that you pay to switch. It is not reasonable that you cannot switch.

Test the ownership question with a concrete scenario

We always recommend that clients put this question to potential partners:

"Say we have worked with you for two years. We are happy with the system, but have decided to build our own team and take over further development. What is the concrete process, how long does the handover take, and what does it cost?"

The answer reveals a great deal. If the vendor:

• Becomes defensive, or asks why you are considering leaving
• Talks about penalty clauses or prior conduct
• Says it "takes a very long time" or "requires specialisation"
• Implies that other vendors will not cope without them

those are red flags. A genuine partner should answer in a structured way: this is the package we provide, this takes four weeks, costs 80,000 in documentation and training, and you are free after that.

If that is the answer, you likely have a partner who wants you to stay because you are satisfied, not because you are locked in.

How STUDIO X handles it

We are consistent: the client owns everything from day one. In practice that means:

• Source code sits in the client's own GitHub or GitLab organisation, not ours
• All cloud services (AWS, Azure, GCP, Vercel) are registered on the client's company with the client's payment card
• Domain names and App Store accounts are registered in the client's name
• Design system, Figma files, source files for icons and illustrations are delivered as part of the deliverable
• Documentation is maintained continuously, not as an afterthought
• Handover to a new partner is part of our standard agreement: up to 60 hours of documented knowledge transfer, at an open and predictable price

We have done handovers for clients before, where we have transferred systems we built to other vendors. It should not happen often, but it should be possible without conflict.

That is the only honest approach: you are our clients for as long as it is a mutually good match. We win by delivering well, not by making you dependent.

Want to talk about what this looks like in a concrete contract? Get in touch, or read about how we work as a development partner.