Cases

What we built.
Measured, not estimated.

Instead of a wall of logos, each case is written out in full: what the client runs, what we built, and what we measured. There is also a factory demo that anyone can open.

Open the live demo

Clients are not named, because none has agreed to it yet. Figures about their business are rounded. Figures about our engineering are exact.

On this page As at 8 Oct 2026
  1. 01WholesaleItaly, selling across the EU · built next to their ERPParallel run
  2. 02DistributionEastern Europe · since 13 Sep 2026, on its own serversIn production
  3. 03Clinic groupSeven clinics in five countries · on invented dataPilot
  4. 04FactoryBatch production · open it yourselfDemo
Parallel run: real data, the old system still decides
In production: the business runs on it
Pilot: built for one client, on invented data
Demo: open to anyone, on invented data
Client 01 · Wholesale

Of 54,000 stock movements, only 612 are open at a time.

Their history holds 54,000 movements, and 612 of them are open at any moment. Their ERP was sized and priced for all 54,000. But every day their team works on those 612, and that is where the ERP gets in the way. A contour (one business flow, built as its own system) is made for that daily work. You cannot see it in a feature list: you have to count it. This gap is the reason a-systems exists.

The client Reference build 01
  • BusinessWholesale distribution
  • MarketItaly, selling across the EU
  • Book of recordOdoo, their own, unchanged
  • Catalogue~92,000 products
  • Trading partners~24,600
  • Sales channels11, five of them integrated
  • History carried over~244,000 invoices and entries
  • Open at any moment612 pickings
Volumes read from their live system, 2 Aug 2026
Case 01

The operations system, built next to the ERP

Order to invoice as a separate system, built on our stand (our private server). Their team works in it on a copy of their live data. Their Odoo stays in place and keeps the books. The three-week promise on this site refers to this build. The migration figure in Evidence on the home page was measured on it. The change count there also covers other builds.

Parallel run
What it does
Built
  • Orders from 5 live channels out of 11 mapped, each with its own connection, costs fixed when the order arrives
  • Stock reserved and shown per bin, not per 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 formats
  • Invoices sent to e-invoicing, fixed and resent if rejected
  • The full interface in Italian, for people who work in Italian
Deliberately not built
  • Accounting. Their Odoo keeps the books, and their accountant keeps working as before
  • Tax localisation beyond the documents we issue ourselves
  • Anything their team could not extend without us afterwards
  • A migration of the ERP. Nothing they run today was replaced
Measured
10,000+
Automated checks on this build and its foundation. Every one must pass before a change goes in
780+
End-to-end tests through a real browser
<100 ms
To take in a channel order and update all the stock behind it. The limit we set is two seconds
180+
Written specifications, each approved before we built it, with every task in it done

People underestimate the specifications. More than 180 were closed on this build alone. Each one is a document that says what will exist, what will not, and how anyone can check that it works. They keep the system easy to change: every later change starts from them.

Case 02

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

Every ERP project is accepted on invented data, then meets real data on the first Monday. We did the opposite. We built a copy of their live business, loaded from their own live system. Their team worked in it before the cutover was even scheduled.

Rehearsed
How it ran
The load
  • 630,000+ rows and over 200 MB copied from their live system in under 4 minutes
  • Loaded, then reconciled line by line as at the cutover date, not as at today
  • No sample data, no invented stock, no made-up history. The stand will not start if any of them is present
  • Their encryption key never left the laptop it belongs to
What it caught
  • Customers who exist only as a secondary address on an invoice, which demo data never shows
  • Ageing reports that changed once real due dates were in
  • A margin that showed as 100% because a cost column was empty, not zero
  • Rounding errors on half cents that a small test data set does not catch

None of these four is unusual. All four are invisible on sample data. All four would have appeared in the first week of live use. We fixed all four before anyone depended on the result. If you have only seen a system on invented data, nobody has really tested it. A rehearsal on real data takes a day, and it is part of the three weeks.

Case 03

A second system, on the same data model

A separate system for the same distributor, with its own code and its own database. It shares the data model for products, partners and prices that the first system set up. This case is about cost.

Parallel run
Why it matters to you
What carried over
  • The data model, so a product means the same thing in both systems
  • The way we work, the testing rules and the release tools
  • The deployment scripts, unchanged apart from a port and a name
  • Price calculation, written exactly once, on purpose
What that gives the next client
  • The migration fee is fixed before signing, not estimated as a project
  • The hard part of distribution is already understood and tested
  • Three weeks is a real schedule, because the business is not new to us
  • The reference build is not a product you buy. It is the reason yours is quick
Client 02 · Distribution

Specified on a Sunday. Taking real orders on the Monday.

A distributor with a web shop, two marketplaces, a phone that rings all day, and books kept in the same accounting system for years. On Sunday 13 September 2026 we wrote the specification in the morning. By night the system was running on a server in the client’s own cloud account, with their customers and order history loaded. The first live orders came through it on the Monday.

The client Reference build 02
  • BusinessWholesale and retail distribution
  • MarketEastern Europe, selling nationally
  • Book of recordTheir existing accounting system, unchanged
  • Customers~9,200
  • Sales channelsWeb shop, two marketplaces, telephone
  • Selling entities3, in one system
  • Orders~11 a day
  • ServersTheir own cloud account, in the EU
Read from their live system, 8 Oct 2026
Case 04

All channels in one system, the books left where they were

Web shop, marketplace and phone orders, the warehouse, fiscal receipts, delivery papers and three selling entities, in one system on the client’s own servers. Their existing accounting system keeps the books and gets what it needs every fifteen minutes.

In production
What it does
Built
  • Web-shop orders arrive automatically, followed by their payment, receipt and refund
  • Two national marketplaces checked every 3 minutes, each with its own connection
  • Phone orders entered at the desk take the shop’s next order number, so there is one numbering series
  • Three selling entities in one system, each order routed to the right one by how it is paid
  • Fiscal receipts through the national fiscal service, delivery papers in the country’s own forms
  • Courier waybills are read back into the system, and the warehouse scans with a phone
  • Invoices, receipts and purchases go into their accounting system as drafts every 15 minutes, for their accountant to post
Deliberately not built
  • Accounting. Their existing system keeps the books, and their accountant keeps the last word on every entry
  • The web shop. It keeps checkout and payment, and the system takes over once the order is placed
  • Payroll and HR: for a team this size, it would be one more set of rules to maintain
  • Manufacturing. They buy and sell, they do not produce
Measured
1 day
From the written specification to live orders, on a server in their own cloud account
~240
Orders through it in its first 25 days, from the web shop, the telephone and a marketplace
112
Releases in 22 days, each checked before it reached them
541
Past orders moved over on the first night, with 7,984 customers. The total matched their shop’s to within one unit of currency

Their requests arrive as screenshots with arrows drawn on them. Seven points raised on 30 September went live the same day, in two releases. A list sent late on 3 October was done by the next evening. That is what 112 releases in 22 days means in practice: the system keeps pace with the people who use it. Every release is checked before it reaches them. In the other direction, 14,675 historical documents come back from their accounting system, so each customer card shows what the books say.

Client 03 · Clinic group

A working system instead of a quotation.

A group of seven private clinics in five countries asked for a small first step: three new clinics, invoicing, a basic CRM and basic finance. Instead of a quotation, we built the system, on the same core the distributors use. The next conversation took place inside it.

The client Reference build 03
  • BusinessPrivate medical clinics
  • Clinics7, in five countries
  • Users at full scope~100
  • First stepThree new clinics
  • Data on the pilotInvented, by rule
  • In productionNot before January 2027
Pilot running since 16 Aug 2026, presented 6 Oct 2026
Case 05

The pilot: working on day one, extended over seven weeks

Patients, inquiries, invoices and payments for clinics that each keep their own books within one group. Each clinic numbers its invoices without gaps. A receptionist sees only their own clinic. The server enforces this; it is not just hidden on the screen.

Pilot
What it does
Built
  • Patients with tags, segments and birthdays, and inquiries that become patients in one step
  • Invoices numbered per clinic without gaps, locked once issued, cancelled but never deleted
  • Payments, overdue amounts, and receivables by age
  • Double-entry books per clinic, each clinic its own company inside the group
  • A dashboard for each clinic and one for the group
  • Roles checked on the server, and each clinic’s data closed to the others
  • Documents and a written history on every record
  • Staff from contract to payroll, and documents to sign
Deliberately not built
  • Appointments and doctors’ calendars: the group chose to leave them until after the first step
  • Medical records, laboratory documents and insurance workflows
  • Integrations and a migration: the three clinics are new, so there is nothing to carry over
Measured
1 day
From the first line of code to a working pilot with invoicing, patients and the books of three clinics, on 16 August 2026
95
Increments of work in seven weeks, each specified in writing before we built it
0
Real patients on it. The data is invented by rule. Every release checks each text column in the database against a list of real names, and stops if it finds one

What carried over from the distributors: the core package every build runs on, at the same version; the standard every screen follows; documents and record history; the release and rollback scripts. What did not carry over: the business logic. A patient is not a customer, and a clinic’s invoice series is not a warehouse’s. So we wrote that part new, and that is the real cost of a new industry. The rest is why the first working version took a day.

Build 04 · Manufacturing

A factory demo you can open yourself.

This is not a client yet, and we do not present it as one. It is a batch production factory with invented names and real workings, open to anyone. Sign in as production, quality, purchasing or finance and run the day yourself. When the first factory signs, this section becomes its case.

Open the factory
The build Reference build 04
  • BusinessBatch manufacturing
  • ProductionBy batch, from recipes
  • Ways inProduction, quality, purchasing, finance
  • Sign-upNone
  • DataInvented, by rule
  • CoreThe same as clients 01 to 03
Open to anyone since 18 Sep 2026
Case 06

From recipe to packed lot, with weighing built in

Production orders from recipes, weighing against a tolerance, lots with expiry dates from the moment they arrive, cleaning between runs, and packing on the screen the floor really uses.

Demo
What it does
Built
  • Recipes with a tolerance on every active ingredient, and production orders numbered without a gap
  • Work centres by type, each with the screen its operators need, on a tablet
  • Weighing per order: a line outside its tolerance is refused, and accepting the deviation takes a signature from someone who did not weigh it
  • Lots created at receipt with expiry and retest dates. An expired or blocked lot cannot be used
  • Cleaning orders created automatically between runs on the same day
  • Finished lots traced one step back and one step forward
  • An interface for a scale to send the weight itself, so nobody has to type it
Not built yet
  • Compliance packs: recalls under US food safety law first, then Canada, the EU and the Gulf, each built with the first client in that market
  • A connected scale. The interface exists, but no scale sends data to this demo
  • Real figures. Nothing on it belongs to a real factory
Measured
3 days
From the approved specification to a working factory day: recipes, production orders, weighing, packing and the floor screen, 21 to 23 August 2026
4
Ways in, one per role, with nothing to sign up for
0
Real names on it. Every release checks each text column in the database against a list of real names, and stops if it finds one

Most factory demos look perfect: every order completes and every weight is exact. Here, one weighed order has an accepted deviation and one packed run has scrap, because a real day has both. Open it, try to break it, and tell us where it does not match your floor.

You have read ours.
Now count yours.

Send your requirements for a free scope read: our written reading of what you need. It comes back the same day as a private page, showing what your own 612 is likely to be. It is not a quote. The price is fixed later, in a written scope.

Open the live demo See every price No call. No card.

Which business should the demo show?

Each one opens in a new tab. The data is invented and rebuilt every few hours. No call, no card.

DistributionWholesale, sales channels and the books ManufacturingA factory floor, batch by batch ServiceA service desk, its engineers and repairs

Next: clinic groups and schools, on the same foundation.