The most important question in a custom software project is rarely asked: what happens if we part ways? Not because you’re planning to leave, but because the answer determines how free you are while you stay. A supplier who knows you can’t leave has no reason to stay sharp on price, quality and pace.
That dependency is called vendor lock-in: switching to another party has become technically or financially unworkable. With custom software, that risk is real, because code, knowledge and infrastructure all sit with one party. The good news: lock-in almost always takes root at the start of a project, which is exactly where you can prevent it.
Where the dependency creeps in
Sometimes the lock-in sits in the technology. An application built on a no-code or low-code platform only exists within that platform; leaving means starting over. The same goes for custom-built frameworks that only the supplier understands, and for services tied to one specific cloud provider. If nobody else works with it, nobody else can take it over.
Just as often, the lock-in sits in the contract. Some developers keep ownership of the source code for themselves, or deliver without documentation and without agreements on what happens if you part ways. At that point the technology barely matters: legally, you have nowhere to go.
The questions to ask before you sign
You don’t need to be a developer to prevent lock-in. Mostly, you need to ask the right questions early, and you can do that in the very first conversation:
- Who owns the source code after delivery, and is that written into the contract in so many words?
- Do you develop with open, widely used technology that other developers could also work with?
- Does the application also run outside your own platform or infrastructure?
- Can I export my data in a standard format at any time?
- What documentation comes with delivery, and is it kept up to date?
- What’s arranged for the end of the relationship: handover, notice period, costs?
A supplier who’s unsettled by these questions has just given you their first answer.
What you want to hear in the answers
Source code ownership should sit with you, in black and white, from the moment of delivery. At eenvoud that’s the standard agreement: the code we develop for you is yours, including the freedom to take it elsewhere. That might look like it works against our own interest, but the opposite is true: a client who can leave and stays anyway, stays for the right reasons.
Keep asking about the technology, even if it isn’t your own field. Open source languages and frameworks with a large community mean another party can be found tomorrow who understands your system. Standard databases and exportable data formats mean your data stays yours. That’s why we develop with open technology and never put a no-code platform between you and your application. For business-critical systems, an escrow arrangement is also worth considering: the source code held by an independent third party, so you can still get to it even if your supplier goes bankrupt.
Documentation is the third test, and the most underrated one. Without up-to-date documentation, a new party can’t take over your system, however open the technology is. For how to arrange that, read our article on good documentation for custom software.
An exit makes the relationship stronger
Talking about the end at the start of a relationship might feel uncomfortable. Still, a clear exit is in everyone’s interest: it keeps your supplier sharp and gives you the peace of mind to think about the challenge itself, rather than the relationship. A system built to be transferable can, if needed, be picked up by another party for ongoing development and maintenance. Knowing that alone changes the balance.
Starting a custom software project? Hold these questions up against the quotes you receive, and feel free to ask them of us too. Our approach to custom applications is built so that you stay because you want to, not because you have to.