Your builder is gone and nobody dares touch it.
Somewhere there is software your company leans on, and the people who built it are gone. Stopped, sold or simply not answering. What you are left with is a system that works, right up until the day it does not.
We take that over. We read ourselves in, write down how it fits together and put the maintenance in our name. After that we keep building, so you can ask for things again instead of hoping it keeps running.
Four reasons why people call us about existing software.
Hardly anyone calls because things are going well. Usually something changed and it stopped running by itself.
-
The builder is gone
Stopped, sold or simply out of reach. It still runs, only there is nobody left to call when something has to change.
We pull the code, run it locally and write down how it fits together within two weeks.
-
You want to leave your supplier
But you do not dare, because you have no idea what is under the bonnet or whether anyone else can work with it.
We first check whether taking it over is sensible. If it is not, you hear that before you cancel your contract.
-
One person knows how it works
And they are leaving in two months. Everything they carry in their head walks out with them.
We sit down with them while we still can and record what has never been written anywhere.
-
Nothing has been done in years
It has run fine all that time. Now something has to be added and nobody dares touch the first line.
Updates and tests first on the parts that matter. The new wish comes after that.
This is what we almost always find in inherited code.
We do not pretend to expect a tidy codebase. This is what we run into in practice, and what we do about it.
-
No documentation
That is the rule rather than the exception. We write it down while we read. That documentation stays yours, even if you pick another party later.
-
An old PHP or framework version
Usually manageable. It gets awkward when there are packages in there that stopped existing years ago. Then we look for a replacement or rebuild that part.
-
Passwords sitting in the code
More common than you would like. That is the first thing to go, along with the keys that were once emailed around.
-
Not a single test
Then we start where the money flows: ordering, paying, invoicing. The rest follows later, once we are in that corner anyway.
-
A server nobody can get into
We once found a machine sitting in a former employee's attic. We move that, data and all, to something that is actually watched.
-
A folder holding backup-final-real.zip
Funny until you need it. We put a back-up in place that runs by itself, and we restore it once to check that it actually works.
From getting access to building again.
No big bang. We take it over in pieces, so you can call it enough at any point.
Book a call-
We read ourselves in
You give us access to the code and the servers. We run it locally, click through it and write down what is there. You do not have to explain what we can find ourselves.
-
You get it in writing
What runs, what is broken, the risk of doing nothing and what it costs to get it healthy. In plain language, not a report you need a developer to read.
-
Maintenance moves to us
Access, domains, servers and monitoring transfer. Everything stays in your name. If you want to leave later, you simply take it with you.
-
We keep building
Fixed sprints and a fixed release day. First the things that hurt, then the wishes that have been on a list for two years.
Platforms we picked up.
Software built by someone else, picked up by us and taken further.
All cases-
De vernieuwde site met een configurator waarin klanten hun eigen pakket samenstellen en meteen bestellen.
Bestellingen die binnenkomen zoals de klant ze zelf heeft samengesteld, klaar om te verwerken.
-
De app en de API waarmee een SOS binnen seconden bij vrijwilligers in de buurt ligt.
Een SOS die binnen seconden op de telefoon staat van vrijwilligers een paar straten verderop.
-
De app die hun magazijnsysteem en Shopify aan elkaar knoopt, te installeren vanuit de App Store.
Voorraad die in het magazijn afgaat en op hetzelfde moment in de webshop klopt.
Moved to Shopify quickly and without worries. Personal contact and a response time you never have to wait for.
Questions about a takeover.
Not answered here? Just ask. You get someone who does these takeovers themselves.
Ask your questionDo you take on everything?
No. Sometimes our advice is not to take it over but to start again, for instance when it sits in a language or framework hardly anyone works with any more. We will say so, even though we earn less from it in the short term. Spending half a year tinkering with something that has to be replaced anyway costs you more in the end.
What if the code turns out to be really bad?
Bad code is not the same as unusable code. Plenty of platforms that look rough on the inside have run fine for years. We look at what actually creates risk: security, data that could be lost, and the parts your revenue runs through. The rest we tidy up while we are there.
Do I need a code scan first?
You do not have to, but it saves hassle. The scan is two weeks of work and gives you a report with the risks, an order and a figure. After that you know what you are getting into and so do we. If you continue with us, that report is the plan.
Can my current supplier obstruct this?
It happens, and it usually comes down to access to the servers or the domain. Always ask for the source code, the repository and access to your hosting. In the Netherlands that is simply yours. If it stalls, we help you write the email asking for it.
How long will my platform be down?
It will not be. A takeover is not a move where the lights go out. We first run a copy next to the existing environment and only switch once everything works. When servers move, we schedule it outside office hours, and then you are talking minutes.
What does a takeover cost?
That depends on how big it is and what state it is in. After the first two weeks you hear a figure we hold ourselves to, not a range that hides a surprise. The call and the first estimate cost nothing.