Rebuilding the management system of a 60-company buying group

This page describes the rebuild of the management system of a 60-company buying group: a Lyon-based group of more than 60 member companies and around fifty approved suppliers, working in refrigeration, air conditioning and professional kitchen equipment. Its website and management application ran on a monolithic proprietary framework that had become a brake. We replaced it batch by batch, at a fixed price, without stopping the group's operations.

The starting point: a frozen foundation

By French standards the group is a mid-sized structure, yet it runs the same processes as a far larger central body: assessing membership applications, negotiating and renewing annual approval agreements with some fifty suppliers, collecting revenue declarations, computing year-end rebates, and retaining the contractual evidence behind all of it.

The public website and the management application shared one foundation: a monolithic proprietary framework, chosen years earlier, that had become the main constraint. The problem was never an outage — the system ran every day — it was immobility. Each change cost more than the last, skills for that stack were getting scarce, and the functional scope had frozen on the day the framework stopped moving.

This is the classic position of a member network with no IT department: the system is neither broken enough to force a decision, nor flexible enough to follow the organisation. So people work around it — and the workarounds end up being the real information system: a workbook here, a shared mailbox there, a network folder for the agreements.

What was stuck, process by process

None of these processes was missing before the rebuild. All of them existed — they simply lived outside the tool that was meant to carry them.

How the project was split and sequenced

A full rebuild sells easily as one block and delivers very badly that way. The project was split into batches ordered by business dependency rather than technical convenience: each batch had to be usable in production before the next one started, and every two-week sprint ended with a demo.

1. 1

   Scoping and data model

   Workshops to write down the rules as they were actually applied: member statuses, the life cycle of an approval, the scope of declarations, the mechanics of the scales. Deliverable: a data model and a fixed-price scope, before the first line of code.

2. 2

   Portal and identity foundation

   The first batch to go live: member and supplier accounts, roles and permissions, reference data. Without it, none of the later processes has anywhere to live.

3. 3

   Supplier approval and document management

   Application and annual approval workflows, with the DMS alongside: agreements, amendments and supporting documents attached to the supplier and the campaign, searchable by content.

4. 4

   Revenue declarations

   The collection module went live before the calculation engine, deliberately: a clean campaign was needed to give the engine a reliable base to work from.

5. 5

   Rebate calculation engine

   The last functional batch, and the one that consumes everything else. Acceptance ran the engine against an already-closed campaign, then investigated every discrepancy until it was explained or corrected.

What was delivered

• A member and supplier portal, in which each party sees only its own scope.
• The approval workflows: application, assessment, annual agreement, amendments, renewal.
• A revenue declaration module, with visible campaign progress.
• A year-end rebate engine running the group's actual scales.
• A document management system that searches inside the agreements, not just across file names.

The terms are part of the result: a firm fixed price, two-week sprints with a demo, a dedicated project team — project manager, senior back-end developer, front-end developer — source code handed over to the group, and contractual maintenance once steady state was reached. MEKANO is a Lyon development studio that works only on this kind of management software for buying groups, co-operatives and member networks; that focus is what makes a fixed price viable across a scope this wide.

The technical decisions, and what justifies them

The platform runs on Go, React and PostgreSQL. None of those choices was made on taste: each answers a concrete constraint of this group's business.

One last criterion weighed as much as the others: longevity. The previous platform did not die of its features, it died of its foundation. Anything depending on a single vendor was ruled out in favour of three widely adopted technologies — ones the group can hire for, have audited, or hand to another supplier without a rewrite.

What was hard

Three things, and not one of them was a development problem.

Migrating the data

Data from an ageing system is not wrong, it is ambiguous: the same supplier present several times because the legal name changed, agreements with no end date, declarations tied to the calendar year for some and to an offset financial year for others. The migration called for judgement calls rather than code, made with the people who knew the history of each case. It was the heaviest demand on the group's own time, and it should be budgeted from the scoping stage.

The rules nobody had written down

The specification described the scales. Practice held more: a long-standing exception granted to a historic supplier, a pro-rata method applied from memory for years, a rounding rule never formalised. They all surface at the same moment — when the engine meets an already-closed campaign and the amounts do not land. Working through them one by one is tedious and non-negotiable: this is where members' trust in the new tool is won.

Adoption, on the supplier side above all

Members adopt a portal quickly when it simplifies an obligation they already have. Suppliers have no structural reason to change habits: filing in a dedicated space asks an effort of them that email never did. The switch was handled by supporting the first campaign closely, keeping a fallback channel for latecomers, and accepting that part of that campaign would still run the old way. Planning for that lag stops it being read as a failure.

What the group gets out of it today

We will not publish a time-saving percentage: the before was never measured in conditions that would make the comparison honest, and an invented figure always turns on whoever quotes it. What can be observed is of a different kind.

• A rebate amount can be justified to a supplier straight from the platform, with no manual reconstruction.
• A declaration campaign has readable progress while it runs, rather than a count made afterwards.
• An agreement is found by its content — a clause, a rate, a name — not by remembering the file name.
• A functional change is quoted and delivered inside a sprint, instead of hitting the limits of the old foundation.
• The source code sits with the group, which can have the platform audited or change supplier.

The rebuild did not remove work, it moved it. Time once spent reconstructing, chasing and re-keying now goes into checking, assessing and negotiating. That shift is less spectacular than a percentage, but it is the one a group's general manager notices first.