Three distinct properties determine who truly owns a digital tool: the code that runs it, the data it holds, and the configuration or model that encodes your business rules. A contract that guarantees an accessible code repository, an export available at any time, and the right to have the tool evolved by a third party addresses all three. Most SaaS contracts — and a share of poorly drafted custom development contracts — address none of them.
Three properties, three different questions
The first property is the code. Does a repository exist — a space where the source code lives, versioned and dated — that you have real access to, or only the promise that it will be handed over if you ask? The difference between the two only becomes visible the day the relationship turns sour.
The second is the data. Can you extract it in full, in a usable format, the moment you decide to, or do you have to open a support ticket and wait on someone else's goodwill? That's the question I go into in detail in How to migrate your data out of a SaaS without breaking anything.
The third property is the one most often forgotten: configuration, or the model. The workflows patiently built in a no-code tool, the business rules configured in an ERP, the fine-tuning of an AI model on your own data — all of this work has real value, but it often lives entirely inside a tool you do not own. The day you leave, that logic stays with the vendor, because it was never really yours — only rented along with everything else.
What does "ownership" actually mean in a contract?
The word "owner" slips easily into a sales brochure and far less easily into a precise contractual clause. Three elements turn the intention into a verifiable reality.
A code repository accessible on an ongoing basis, not just handed over once the project is closed: you must be able to access it at any time, not only when the provider decides to open it up to you. A self-service data export, available without depending on the vendor's intervention — the difference between a button you press yourself and a request you make while hoping for a reply. And the explicit right to have the tool evolved by a third party: no exclusivity clause tying you to the original provider for any future change, and documentation thorough enough for another developer to pick up the work without having to guess.
Owning a tool therefore requires these three distinct properties — the code, the data, the configuration or model — each meeting the same standard: real access, not a promise.
Custom-built done properly delivers the code by default
This is a commitment I consider non-negotiable in my work: when I build a custom tool, the code repository belongs to the client from day one, without them needing to ask, and at no extra cost to access it. The site you are reading right now, mcva.ch, was rebuilt on exactly this principle — code that is accessible, documented, and transferable should I one day stop being the only one working on it.
FiscalDoc, the local application I built for my own tax filing, takes the same principle to its logical end: I own the tool, I own the code, I own the data, I even own the AI model that analyzes it. I documented this case in FiscalDoc: replacing CHF 1,400/year of SaaS with local AI. It's not a matter of trusting the provider — it's a matter of contract, and a well-scoped custom project settles it from the outset, not after the fact.
The traps of in-house CMSs and captive configurations
The most misleading trap isn't the classic SaaS, which is fairly easy to recognize as rented. It's the "in-house" CMS or tool, built by an agency and presented as an asset belonging to the company, when in fact the code is documented nowhere, no repository is accessible outside that agency, and any change necessarily has to go through them. The phrase "custom-built" has been used to dress up a lock-in every bit as strict as a closed SaaS — sometimes more so.
Captive configuration follows the same logic by a different route. Weeks spent configuring automations in a no-code tool, building complex scenarios in a CRM, fine-tuning rules in an ERP: this work has real value, but it exists only inside the license that runs it. The day you want to leave, that logic doesn't export — it stays locked in a format only the vendor can read.
A few signs reliably reveal a tool that doesn't actually belong to you:
- no accessible code repository, only the provider's word;
- exporting requires a support ticket rather than a self-service action;
- no technical documentation lets a third party pick up the work;
- no one other than the original vendor has ever actually been able to intervene;
- your business logic exists only in a proprietary format, unreadable elsewhere.
How to check what you actually own, starting today
The exercise doesn't require deep legal expertise to get going: ask every provider in your software stack the same three fundamental questions — where is the code, how does the data get out, who can evolve the tool tomorrow. The answers, or their absence, immediately place you on the scale of real ownership.
This inventory connects with the one I recommend in nFADP: where does your SME's data actually live?: knowing where your data lives is half the work, knowing who holds the keys to it is the other half. It also connects with the question of hosting — Swiss hosting says nothing about who owns the code running on it, as I explain in Hosting in Switzerland: what it actually changes — and with the question of exit, the day ownership turns out to be insufficient and migration becomes necessary, covered in How to migrate your data out of a SaaS without breaking anything.
The right time to clarify these three properties is never after a dispute. It's before signing, or failing that, at the next renewal — it's one of the points I systematically check when scoping a custom-built solution, and one of the topics I return to in What should a Swiss SME do about AI in 2026?
Key takeaways
— A digital tool is owned through three distinct properties: the code, the data, and the configuration or model that encodes your business rules. — "Ownership" means nothing without an accessible code repository, a self-service export, and the right to have the tool evolved by a third party. — Custom-built doesn't automatically protect you from lock-in: a poorly documented in-house CMS can lock you in just as much as a closed SaaS.
FAQ
If I paid for custom development, does the code automatically belong to me? Not necessarily. It all depends on the contract terms: an explicit assignment of rights is nothing like a simple usage license, even when the invoice looks identical. Check the intellectual property clause — in contracts already signed as well as future ones — rather than assuming it's in your favor.
Is a "proprietary" CMS built by my agency necessarily a problem? Not necessarily, but it deserves a check. An accessible, documented code repository, even with a single provider, remains manageable. The real problem appears when nothing is documented and no one else could take over if the relationship ended tomorrow.
I'm discovering that I don't own what I thought I owned — what should I do? Start with an inventory rather than a confrontation: which tools, which data, which code, held by whom. Then raise the ownership question at the next contract renewal, the moment when the vendor has the most to lose by refusing. For truly critical tools, a custom rebuild sometimes becomes the safest long-term solution.
Do I own an AI model I fine-tuned at a vendor's platform? Generally, no, by default: the base model remains the vendor's property, and your fine-tuning usually stays under license rather than being transferred to you. Terms vary widely from one vendor to another — it's a clause to read before investing time in fine-tuning a model, not after.
Does owning your code necessarily cost more than renting a SaaS? Not always, and the gap has narrowed in recent years: AI-assisted development has lowered the cost of building a custom tool, as I documented with FiscalDoc. The question deserves to be asked afresh, function by function, rather than settled by habit.
Can't say today who actually holds the code to your tools? The AI Usage Diagnostic: sixty minutes to lay out your real workflows, identify what deserves custom-built treatment, what stays in SaaS, and what doesn't need AI at all. Book a diagnostic
Jérôme Deshaie is CEO and founder of MCVA Consulting SA, an augmented agency based in Valais. Fifteen years serving major international brands, now working directly with Swiss SMEs. Background.