A twenty-year-old broker system, rebuilt without retraining anyone

The problem

The business ran on a SQL Server application built in 2003, sitting on a server in the office, and the people who used it had twenty years of muscle memory in it. Replacing it meant one of two bad outcomes: keep the old thing and its risks, or buy a platform priced per seat for enterprises, use a fraction of it, and reshape an unusual process to fit somebody else's model. Brokering runs on specifics. Vendor-to-vendor shipping, freight riding on the tooling line, a capability vocabulary built up over decades. No off-the-shelf system handles that. Meanwhile the daily work was slower than it needed to be: around 90% of what the office does is repeat business, and duplicating a 60-line inquiry meant deleting forty items one at a time, scrolling back down after every single one.

What we built

We rebuilt the whole broker process, from inquiry through RFQ, vendor pricing, customer quote, order, purchase orders, releases, shipments and billing, plus the master files it all hangs off: customers, vendors, materials, and the 93-code vendor capability vocabulary carried across intact. Alongside it sit a CRM for tracking sales opportunities, a set of day-to-day reports, and an admin area for users, sign-in and connections to other systems. The rule throughout was to halve the clicks on the work people really do and let the system think ahead: the new duplicate dialog asks which lines and at what quantity, rather than making someone delete forty of them by hand. Who can see cost and sell prices is controlled in the database itself with Postgres row-level security, rather than by hiding a column on the screen, so a salesperson can see that 15,000 units are being quoted and has no way to see the margin. Every delete is recorded, and if two people edit the same record at once, the second to save can no longer overwrite the first. Two years of history was brought into the live system, with a nightly copy from the old server keeping both systems in step through the changeover.

The outcome

The office kept its vocabulary, its job numbers and its way of working, so the change felt like a faster version of a familiar system rather than a move anyone had to be trained through. Repeat work, which is most of the work, takes roughly half the clicks it used to. Margin is protected in the database itself rather than on the screen, which matters most when the margin is the product. Nothing gets lost without a trace anymore: every delete is recorded, two people saving at once no longer overwrite each other, and every send reports where it really went. The old data stays searchable throughout, and the extract carries the original system's own record counts, so answering "are we missing anything" is a glance rather than an afternoon.