The question that's almost never asked in the sales meeting - and is decisive three years later. About ownership, usage rights, vendor lock-in and the option to move on at any time.
You pay a five-figure sum for your software. But does it belong to you in the end?
Most SMEs only ask this question when it's too late - when the provider raises the price, makes a switch impossible, or simply no longer exists. This page gives you the terms and questions you need to understand the difference between buying and renting.
Whoever has software built often believes they own the finished work in the end. That isn't automatically true.
Ownership of the source code. That's the strongest form: you get the complete code, may change it, pass it on, have it developed further - by another provider too. This form has become rare among SMEs, because it's the least attractive for the contractor.
Usage right without source code. You may use the software, but it belongs to the provider. If they raise prices, cut features or go bust, you have a problem. The most common form with SaaS solutions - but also with many bespoke developments, without it being stated clearly.
Licence for specific purposes. You may use the software, but only in your business, or only for certain use cases. Reselling, your own modifications or changing the maintenance provider are excluded. Often in the small print.
Lock-in means being locked in. In the software business it describes the state where you can no longer get away, even if you wanted to.
There are five typical sources of lock-in. Data format: your data sits in a closed format that only the software can read. Source-code closure: you have no access to the code, so you can't commission another maintenance provider. Platform binding: the software runs only on the provider's servers. Knowledge: only the original developer knows the structure, anyone else would need months to get up to speed. Contracts: the notice periods are so long that a switch isn't realistic.
Lock-in isn't always bad. But it should be your conscious decision, not a result of silence in the contract.
Data protection governs how your data is processed. Ownership governs something else: who can take it if the provider is gone?
Concrete scenario: your software provider becomes insolvent. Your customer data, order history, receipts sit on their servers. In theory they belong to you. In practice it depends on the insolvency administrator whether, when and in what format you get them back. In the worst case they're gone - or behind a wall of lawyers' letters. The right question before signing: "If you no longer exist tomorrow - how do I get to my data?"
Even without legal training, you can check any software contract by asking five simple questions.
One: Do I get the source code in the end - or do I only get a usage right?
Two: If I want to cancel - exactly how do I get my data out? In what format? Within what deadline? Is that in the contract?
Three: If the provider goes bust - what happens to my software and my data? Is there a deposit with a notary (source-code escrow)?
Four: If I want a different maintenance provider - may they touch the code? Is that expressly in the contract?
Five: If the provider raises prices - what are my options? Is there a price guarantee over the contract term?
Not every lock-in is a scandal. Whoever uses standard software like DATEV or Lexware is also bound in a certain way - that's the price for the software being cheap and mature. That's okay.
Lock-in becomes problematic when it concerns your individually developed software that's unique to your business. Here ownership should be clear - otherwise you pay the full price for something that belongs to someone else. The rule of thumb: the more individual the software, the more ownership rights you should have.
We keep it simple. Our standard contracts state: the source code of the software built for you belongs to you as soon as the invoice is paid. You get it handed over at any time on request - complete, runnable, commented.
That means: if in three years you no longer want to work with us, you can commission any other developer to take over the code. We even help with the handover. That isn't generosity - it's a matter of course. If our business relied on no one being able to lure you away, we'd stop treating you well. That's not the business we want to run.
Many software houses build their business model precisely on lock-in. The calculation is simple: if the customer can't get away, the price can rise. That works short-term - but long-term it breeds distrust. Whoever has experienced more than once that software becomes a hostage looks, next time, for providers who act differently.
We believe: binding through quality is more sustainable than binding through hurdles. If you stay with us because our work is good - perfect. If you want to leave because something has changed - you should be able to. That's a poor sales trick and a good business principle.
Ownership isn't only a legal question. It's a question of trust.
Whoever gives you no ownership rights is basically saying: "I don't trust my own work enough for you to be able to use it without me too." Whoever gives you all the rights is saying: "My work holds up on its own. You only need me when I'm genuinely useful to you." We belong to the second sort.
What comes after the build and how maintenance is handled is on Maintenance and further development. What software realistically costs is on What software really costs. Which principles we apply to our own work is on When is software actually good?.