Two weeks of reading. Then you know where you stand.
We get access to your code and your servers, read through everything and put on paper what is there, what goes wrong and what it costs to fix. You are tied to nothing, and the report stays yours even if you continue with someone else.
What lands on the table after those two weeks.
Not a forty-page technical document. Something you can make a decision on.
-
A report in plain language
What runs, how it fits together and where it chafes. Written so you can show it to your board without a translator.
-
Risks in order of urgency
From things going wrong today to things that will bite in two years. With what each one costs you if you leave it.
-
A figure per item
What it costs to solve, broken down. So you can choose yourself what to start on and what to leave.
-
An hour to walk through it
We go over it together and answer everything. Including whether you would be better off starting from scratch.
Also when the code was written by AI.
A lot gets built with the help of AI these days, and it often gets further than people expect. Right up to the moment it has to go into production. Then it turns out nobody can explain why something works the way it does, and whole pieces are missing that you only notice once a customer depends on them.
We read that code the same way we read code typed by hand. Without judgement, because it is not about who wrote it but about what it does.
-
Does it do what you think
AI writes code that looks right. Whether it also holds up against the exceptions in your process is another matter.
-
Is it safe
Permissions, input that is never checked, keys sitting in a file somewhere. Those are the things that get skipped.
-
Can it go into production
Tests, error handling, monitoring and someone who knows what to do when it falls over at night. That part we add.
What we look at.
Six corners, and the same question in each: what happens if this breaks today?
-
Security
Outdated packages, passwords in the code, forms that let anything through. We run a scanner over it as well.
-
Dependencies
Which parts are still maintained and which have been dead for years. That last one often decides whether building on is possible at all.
-
Tests and releases
Is there anything checking that it still works before it goes live, or does that happen on good faith?
-
Speed
Where are the queries that flatten the database on a Monday morning. Usually there are two or three of them.
-
Hosting and back-ups
Where does it live, who can reach it and what happens if that machine dies tomorrow. We restore a back-up once to see whether it works.
-
Handover
Can another developer continue with this, or does it all sit in one person's head. That is the most expensive risk there is.
Request the scan in thirty seconds.
You do not have to hand over access yet. We first check whether a scan makes sense, and say so honestly if it does not.
- Two weeks of work
- Price known up front
- The report stays yours
- The request commits you to nothing
Your request is in.
We will get in touch to agree what we look at and when we can start.
And then this happens.
You will not be left waiting for two weeks. This is what follows the moment you hit send.
-
You get a developer on the line
Not a sales email with a calendar link in it. We ask a few questions and say straight away whether a scan makes sense in your case.
-
We arrange access
To the code, the repository and the servers. If you would rather not hand that over, we look along over a screen at your office.
-
The report is there
We walk through it together and answer everything. After that you decide what happens, with or without us.
Do I have to give you access to my code?
Eventually yes, otherwise there is nothing to read. Not for the request itself. If you would rather not hand it over, we look along over a shared screen at your office. That works less comfortably, but it works.
What if you say it cannot be saved?
Then that is in the report, with the reasoning. Not a pleasant outcome but a useful one: you know that investing further in this platform is money thrown away. What you do next is up to you.
Am I committed to anything afterwards?
No. The report is yours and you may take it to another party. That happens, and it is fine. We would rather you make a good decision than stay with us because you have nowhere else to go.
How long does it really take?
Two weeks from the moment we have access. With a small platform we finish sooner; with something ten years old and several integrations we say up front that it will be three.
What does a code scan cost?
It depends on the size: a two-year-old webshop is a different story from a platform with five integrations and ten years of history. After the first call you hear a fixed figure, not a range. If it turns out to be more work, that is our problem.
Will you see our customer data?
As little as possible. We prefer to work with a copy of the database in which names and email addresses have been replaced. If that is not possible we sign a processing agreement and use accounts that are closed again afterwards. We agree on this before logging in anywhere.
We have several systems. Can that be one scan?
Often yes, and it usually helps, because the problems tend to sit between systems. We agree up front on what is in and what is out. If there are six, we start with the one your money runs through.
Do you work outside PHP and Laravel?
Yes. Most of what we run into is PHP, WordPress or Laravel, but we read .NET, Node and Python too. If it sits in something we do not know, we say so straight away instead of trying it at your expense.
What if we want to fix it ourselves afterwards?
Fine. The report is written so your own developer or another party can work with it. There is not a single step in there that only we can take.
Do you do this while we are with another supplier?
Yes, and it happens often. You do not have to tell your current supplier anything. We write down what we see, without judging whoever built it.