Keeping ownership of your system, even without being technical

Many systems work perfectly well — until the day you need to change a part. Switch provider, host, or tool. That is when you discover who really owns the system: you, or the person who built it.

The exit test

The most honest question to ask a provider is not “what can you do?” but “if we stop working together tomorrow, what do I keep?”. The code, the access, the data, the documentation, the ability to run the system elsewhere. If the answer is vague, ownership is vague.

The explanation test

You do not need to understand every line of code. You need someone to be able to explain, simply, what the system does, where your data lives, and why the technical choices were made. A system that cannot be explained simply is either too complex or deliberately opaque. Both are problems.

The dependency test

How many parts of your system depend on a service you do not control — and what happens if one of them disappears or triples its price? A dependency is not bad in itself; an unidentified, irreplaceable one is.

Ownership is not a matter of technical skill. It is a requirement to state from day one — and a sober, readable, documented system is precisely what makes it possible.