Cases

One distributor.
Three systems.
Every number on this site.

We have one reference client, not a wall of logos, and pretending otherwise would be the first thing you catch us on. So here is that one client in full: what they run, what we built, what it measured, and the three things this does not prove yet.

Client unnamed by agreement. Figures on their business rounded, figures on our engineering exact.

The client Reference build 01
  • BusinessApparel wholesale distribution
  • MarketItaly, selling across the EU
  • Book of recordOdoo, theirs, untouched
  • Catalogue~92,000 products
  • Trading partners~24,600
  • Sales channels11, five of them integrated
  • History carried~244,000 invoices and entries
  • Open at any moment612 pickings
Volumes read off their production system, 2 Aug 2026
Why one client

The last line of that card is the whole reason this business exists.

Six hundred and twelve. Out of fifty four thousand movements in their history, six hundred and twelve are open at any moment. Their ERP was sized for the fifty four thousand and priced for the fifty four thousand, and every day their team fights it over the six hundred. That gap is what a contour is, and you cannot see it from a feature list. You have to go and count.

Case 01

The operating system, built beside the ERP

Order to invoice as its own system on their server, with their Odoo left in place as the ledger. This is the build the three week promise on this site refers to, and it is the one every figure in Evidence was measured on.

Running
What it does
Built
  • Order intake from 11 channels, one door each, costs frozen on arrival
  • Reservation and availability by bin, not by warehouse total
  • Pick, pack and label by barcode, on the floor, on a phone
  • Purchasing with a three way match against the receipt
  • Delivery notes in all four Italian DDT shapes
  • Invoicing into the fiscal chain, with fix and resend on rejection
  • The full interface in Italian, for people who work in Italian
Deliberately not built
  • Accounting. Their Odoo keeps the book and their accountant keeps their habits
  • Fiscal localisation beyond the documents we raise ourselves
  • Anything their team could not extend without us afterwards
  • A migration of the ERP. Nothing they run today was replaced
Measured
2,378
Automated checks, every one of them green before a change can merge
44
End to end journeys driven through a real browser, nightly
73 ms
To accept a channel order including the whole stock chain, against a two second budget
35
Specification increments, each written and approved before it was built

The specifications are the deliverable people underestimate. Thirty five of them, each one a document that says what will exist, what will not, and how anybody will know it worked. That is what makes the repository handover grade instead of merely working, and it is why their own AI can extend it after we are gone.

Case 02

A rehearsal on their real data, before anybody depended on it

Every ERP project is accepted on invented data and then meets reality on the first Monday. We built the opposite: a mirror of their live business, loaded from their own production, that their team worked in before cutover was even scheduled.

Rehearsed
How it ran
The load
  • 632,873 rows and 219 MB pulled from their live system in 3 min 20
  • Loaded, then reconciled line by line as at the cutover date, not as at today
  • No demo seed, no invented stock, no backfill. The stand refuses to boot with them
  • Their encryption key never left the laptop it belongs to
What it caught
  • Customers who exist only as a child address on an invoice, invisible on demo data
  • Ageing reports that read differently once real due dates arrived
  • A margin that showed as 100% because a cost column was empty, not zero
  • Rounding on half cents that a small fixture stays green through

None of those four are exotic. All four are invisible on a seeded database, all four would have surfaced in week one of live running, and all four were fixed before a single person depended on the answer. A system you have only seen on invented data is a system nobody has tested. Rehearsing on the real thing is a day of work and it is in the three weeks.

Case 03

The second system, on the same domain model

A separate system for the same distributor, its own repository and its own database, sharing the model of products, partners and prices that the first one established. The point of it is the cost, not the feature list.

Running
Why it matters to you
What carried over
  • The domain model, so a product means the same thing in both systems
  • The delivery workflow, the test discipline and the release machinery
  • The deployment scripts, unchanged apart from a port and a name
  • Price resolution, which has exactly one implementation on purpose
What that buys the next client
  • A second contour is priced as a contour, not as a second project
  • The hard part of apparel distribution is already understood and already tested
  • Three weeks is a schedule rather than an ambition, because the domain is not new
  • The reference build is not a product you buy. It is why yours is quick
Honest gaps

What none of this proves yet.

A case study that only contains good news is an advertisement. These are the three claims on this website that our own evidence does not yet reach, written here so that you find them from us rather than in month four.

Everything on this page was measured on a running system, not estimated from a plan. The client is not named because they have not agreed to be, and we would rather publish a case with no logo on it than a logo with no case behind it.

You have read ours.
Now count yours.

The probe is a week, it is free, and it ends with a written document telling you what your own six hundred and twelve is. You keep that document whether or not you go on with us.