An Information System Built to Run Without Us

Most software is handed over in a way that keeps the client tied to the supplier. This year we finished a system where the brief was the exact opposite. What we learned about handing over software when the supplier genuinely walks away afterwards.

Jozef Krivaček · 05/09/2026 · 6 min read

In our industry, "handover" usually means the client gets a set of login credentials and an invoice. The source code stays with the supplier, the documentation gets written "at some point", and if anything breaks a year later, the only people who can fix it are the ones who built it. There is no bad intent behind this. It is simply the most convenient path, and it never shows up in the price of the contract.

This year we finished a project where that path was not available. So we had to think hard about what handing over software actually means.

What the project was

A company that carries out mandatory inspections and tests of regulated technical equipment. Lifts, pressure vessels, boiler rooms, electrical installations. Hundreds of devices across dozens of customers, each with its own legally prescribed inspection interval and a report that has to contain exactly the right details. The whole agenda lived in spreadsheets and in the head of one person who knew what expired when.

We built them an information system that holds all of it together. A device register with history and documents, automatic inspection planning based on the intervals, inspection records with a PDF report, multi-level approval, a colour-coded validity overview showing who has what expired and what is coming up, and roles for technicians, supervisors and auditors. The system is multilingual and ready to serve several companies at once, each with its data fully separated.

An ordinary custom development job. Except for one thing.

Why "without us" was not a figure of speech

The project was funded by Slovak development aid and the recipient is a company in a country outside the European Union. That changes everything. After handover we are not in the same country, we do not speak the same language, and on handover day there is no signed support contract. Maybe there will be one, maybe not. The system has to be built so that it can be operated by someone we have never met and developed further by another supplier if the recipient so decides.

In other words, supplier lock-in was not merely distasteful here. It was impossible, because six months later the supplier may simply be out of reach.

Once you accept that as the brief, you stop treating handover as the last day of the project and start treating it as a product that is designed from day one.

What we handed over besides the code

The source code, naturally. All of it, with no proprietary licences, built on common open technologies that every software company in Europe knows. That was a deliberate choice. An unexotic, "boring" technology base means the next supplier can be found in any regional city.

But code is only the start. Nine documents left with the system, and each has a different reader:

1. User manual for the people who work in the system every day.
2. Technical and administrator documentation with the architecture, data model and interface description, for whoever will develop the system further or connect other systems to it.
3. Security documentation for the security manager and the auditor. How authentication works, how data is separated between companies, what gets logged.
4. Operations manual for whoever deploys and maintains the system. Step by step, from an empty server to a running system, including backups and what to do when something fails.
5. Draft service level agreement for the management that will negotiate support, with whomever.
6. Acceptance test plan with 68 scenarios the recipient walks through on its own and signs off that it works.
7. Training materials split by role, with exercises on demo data.
8. Compliance mapping against ISO 27001, ISO 27018 and GDPR, in case the recipient decides to certify its operation.
9. Phase two proposal: what makes sense to build next and in what order.

Let me pause on the eighth document, because it is the typical place where our industry lies. Most "statements of compliance" are marketing documents. For every control in the standard, we wrote down whether it is implemented in the code, partially implemented, planned, or the operator's responsibility because it concerns hosting and physical security rather than the application. An auditor opening that document two years from now will get something out of it. Out of a sheet where everything is green, they will not.

A service agreement that also says what you will not get

We wrote the draft service level agreement knowing that a supplier other than us might end up signing it. So it contains numbers that can be achieved, not numbers that look good.

Every number comes with a note on why it is what it is and what it would cost to be higher. Availability of 99.5 percent matches a small system on a single server in the EU with no redundancy. If the operator wants 99.9 percent, it needs a second server and a database replica, which is doable, but for different money. We would rather write that into the contract than have them find out during the first outage.

What we took away from it

At first we treated this scope of handover as a peculiarity of a development aid project. Once it was done, we realised it is simply the right way to hand over software to anyone.

A Slovak public authority or company is in the same position as a recipient abroad, it just may not realise it on signing day. A supplier can go out of business, sell the company, or quote a price for the next phase that cannot be refused because nobody else knows the system. For the public sector this is not theory. Dependence on a single supplier is the most common diagnosis pronounced over Slovak government IT, and it is almost always pronounced too late.

So since this project, the same rules apply to every piece of custom development we do as applied to the aid project. The client gets the source code, the operations manual, a documented interface and an acceptance plan they can walk through themselves. And they get a draft service agreement that says honestly what works for the money and what does not.

It is not that we do not want long-term clients. We do. But we want them to stay because we are good, not because they cannot leave.

If you are preparing an information system, whether a new one or a replacement for one you cannot disconnect from, get in touch. We will come back with a proposed scope and a description of what the handover would look like.