On one logistics platform the answer was nineteen, and no two of them agreed. Nobody in the building knew that: not the engineers, not the lead, not the tracker. It is why the estimates kept being wrong, and it is a number you can measure rather than argue about.
Read-only. We do not need production access to be useful.
Third-party logistics operators and shipping platforms maintaining a platform that quotes, bills, allocates stock and talks to carriers. Not businesses buying an off-the-shelf WMS. Typically five to forty engineers, and a codebase between five and fifteen years old. A business where a software defect is a billing error or a shipment that does not move.
If that is you, the rest of this page is measurements from a platform much like yours, with the date each was taken.
A defect comes back. Somebody says "we fixed that already". Nobody can prove whether it is the same one, because each recurrence was filed as new work.
The assessment is a census of your write paths. It runs read-only against your repository, and it answers a question normally settled by opinion. For a given behaviour: how many places implement it, and how many of those disagree with each other.
We publish the commands we ran, so you can re-run any of it later without us. Every figure in the deliverable carries the date it was measured.
A weekly billing process recomputed a charge column for the whole table instead of the billed week. Here is what happened next, in order.
Correct, reviewed, merged. Nothing about it was careless.
Byte-identical to one of the fixed files apart from the missing clause. It was not changed, because nothing pointed at it.
Written to prevent recurrence. It checks a hard-coded list of exactly the three files that were fixed. It is green, and it always will be.
Not the fix, not the review, not the test. The defect survived all three. This is what "we keep fixing the same things" looks like from the inside. A codebase where a fix has no mechanical way to find its own siblings.
Two systems both believe they know a quantity, and they disagree. Anyone can diff two tables. The value is knowing which differences are real, and that comes from calibrating against an export your operators already trust. An uncalibrated reconciliation tool is a source of arguments, not answers.
We have built this. On the engagement we can cite, the calibration step surfaced a second, separate defect in the existing reporting: a ledger-attribution error nobody was looking for. It also found a generated report that contradicted its own totals row, because a row-limit clause interacted with a full-coverage label. That is what looking closely enough to calibrate tends to find.
Each step is worth buying on its own, and each one makes the next easier to scope. Most engagements stop after the first because the document answered the question.
Two to three weeks, fixed price. The duplication and write-path census, the recurrence trace, and a ranked list of what makes change expensive.
Charge and billing reconciliation first, because that is where the cost is legible to the business and where a defect is a customer conversation.
Reconcile platform stock against the fulfilment system, calibrated against an operator-supplied export as ground truth. Project to build, optional retainer to operate.
Pipelines, environments and release process on retainer. We watch every gate fail on a planted defect. More on that here.
If a supplier offers you either of these without a baseline, two questions will usually dismantle it. We would rather not be that supplier.
We did not measure delivery speed before and after on that engagement, so we have no such number and will not invent one. What we can show you is the finding and the deliverable.
We never traced one, and the client's own deliverable says so in those words. What we can show you is how many places a change has to touch. What that has cost you is yours to judge. You have the incident history and we do not.
You have probably been quoted one before, and it is a fair reason to distrust consultancies. The assessment is how you find out whether you need one. On this platform, fifteen function families were duplicated without diverging at all.
The finding is structural. On the platform above, a change to charge behaviour had nineteen implementations to consider and no mechanical way to find them. Those engineers were not slow. They were working without a map.
How many places would a change to how you charge for a shipment have to be made? If the honest answer is "nobody knows", that is the finding. It is what the assessment exists to turn into a number.
We reply within one business day.
Figures on this page come from a 2025–2026 engagement on an enterprise shipping and third-party-logistics platform. We measured them read-only against the production repository's main branch, on the dates shown. The client is not named. Every figure and its measurement basis are recorded in our internal evidence file. Ask and we will show you the working, including the counter-examples. We publish no improvement percentage for delivery speed, defect rate or cost, because we did not measure a controlled before-and-after and will not invent one.
