Five systems, one client, since 2019.
A tyre distributor whose ERP could not be replaced, and the five systems we built around it instead. The first went live in January 2019. The most recent received code this month.
Anyone can build you a system. The question is who answers the phone in year seven.
First commit January 2019, most recent this month. Five systems, none retired.
The situation
The ERP was not going to be replaced. So we stopped trying to work around it.
Gumiimpex-GRP retread, recycle and distribute tyres: a trade business, a consumer-facing service network, and a warehouse operation, all running on one on-premises ERP that predates every system on this page.
The usual advice is to replace it. That would have meant stopping the business for a year to arrive roughly where it started.
We built one piece of middleware in front of it instead, and then built everything else against the middleware. Nothing since 2019 has talked to the ERP directly.
That single decision is why the four systems that followed took months each, and why none of them has had to be rewritten when the ERP changed.
Five systems, added one at a time.
Gumiimpex-GRP retreads, recycles and distributes tyres. We wrote the first line of code for them in January 2019 and committed to their systems again this month. Nothing here was a rewrite. Each system was added beside the last one, while the previous ones kept running.
On-premises ERP, Azure SQL and .NET. Every system reads and writes through the same middleware rather than talking to the ERP directly.
Everything since has been built on this one piece.
The first system was not a system anyone uses. It is the continuous sync between their on-premises ERP and everything that came later: items, partners, balances, stock and documents. Building it first is the reason each system after it took months rather than years.
Five suppliers, arriving on their own schedules, in their own formats.
Price catalogues land nightly and stock every three hours, over FTP and SFTP, in whatever shape each supplier sends. They are parsed into one product catalogue and pushed back out per partner. Seven database connections, six of them reading somebody else's system.
A customer's winter tyres have an address.
Seasonal storage tracked as a warehouse, a shelf and a row, not as a note in a spreadsheet. Every stored set moves with dispatch and delivery documents, and the whole thing stays in step with the ERP. It has run through every twice-yearly changeover surge since it went in.
Two ways to be served, one queue behind them.
Branch screens and printed tickets for people who walk in, and a public booking flow against real service-bay capacity for people who plan ahead. A booking is not real until the customer confirms by email, and it releases the bay automatically after ten minutes if they do not.
The oldest of these has been running for seven and a half years.
Five systems, added over seven and a half years, and every one of them received code this month. That is the whole claim: not that we built something once, but that it is still ours to fix on the day it breaks.
What this case does not claim
There is no percentage on this page.
Gumiimpex have not published an operational figure, so we have not printed one. What is checkable is the timeline: when each system went into production, and that all five are still being worked on. If you want the operator's own account of what changed, ask us during a scoping call and we will arrange it.
