The builder has gone. The application is still running.
We take over existing custom applications and stalled software projects,
even when nobody knows any more how they work. We establish what exists,
what works and what is missing, assess how to move forward responsibly —
even without complete documentation — and then develop it further.
The system became business-critical without anyone deciding it should.
An application built by one person grows along with the work. At some
point the primary process runs on it and whoever made it is no longer
there. Replacing it is expensive and risky; leaving it alone is too.
There is no documentation.
What the system does is in the system. We derive its behaviour from
the code and from how it is used, and we write down what we find —
that document is the first thing you get back.
Nobody dares change anything.
Every change feels like a risk, so changes do not get made. We start
by building an environment where a change can be tested before it
reaches production.
The technology is old, but it is not the problem.
VBA, Access, an old PHP version, Google Apps Script: the tooling does
not decide whether a takeover is possible. What counts is whether the
behaviour can be reconstructed.
It has to keep working during the takeover.
We take over while the system stays in use. A big bang is rarely
necessary and almost never wise.
The builder was an AI.
Increasingly the application was not made by a colleague who left
but by an AI, and nobody ever read the code. With a builder who
left there was at least once a person who understood it; here there
never was. Not because AI writes bad code, but because nobody kept a
record of what had been agreed. We reconstruct the behaviour the
same way, and write it down afterwards.
How we go about it
Understand first, change afterwards.
01
Inventory
What runs, where, for whom, and what happens if it stops. Including
the integrations nobody has in mind any more.
02
Reconstruction
We derive the behaviour from the code and from how it is used, and
record it. AI helps us do that considerably faster; a person remains
responsible for every conclusion.
03
Making it manageable
Version control, an acceptance environment, a release that can be
repeated. Only then is further development responsible.
04
Further development
What has been on the wish list for years becomes possible again.
And the next handover is prepared for rather than feared.
The takeover happens above the line; the system keeps running beneath it. Nothing goes to production until there is an acceptance environment and a repeatable release.
From practice
From a thousand files to one database.
An international technology company ran its planning on more than a
thousand Excel files, merged into one master file. Every change had to be
made in all of those files; three people worked full time just to keep it
running.
We rebuilt the set-up into one read-only template with a central
database. Maintenance has all but disappeared, and since then the project
team has worked on new functionality instead of fighting fires.
Tell us what runs and what goes wrong if it stops. We will say honestly
whether a takeover makes sense — sometimes the answer is that replacing it
is cheaper.
