A reference architecture for a common situation: a company running on dozens of interlinked spreadsheets, past their limits, where packaged software does not match the way the business works.
This is a reference architecture, not a client case study. No client names or figures from a specific project appear on this page.
The problem
A business of 30 to 200 people whose operating process has taken shape over years and is something they do well. Data sits scattered across spreadsheets, each department holding its own copy, reconciled by hand at month end.
The symptoms are familiar: two people editing the same file overwrite each other, nobody is sure which copy is current, consolidated reporting takes two days a month, and if the person who understands the spreadsheet web leaves, the company has a serious problem.
Design principles
Digitise the current process, do not impose a new one
A common mistake is to redesign the entire process while building the software. The result is that staff must learn a new way of working at the same time as new software, and the failure rate climbs. Phase one should follow current practice closely. Optimise the process later, once the system is stable.
One source of truth per data type
Each piece of information is entered once, in one place. Everywhere else references it rather than copying it. This is what spreadsheets cannot do, and the strongest reason to move to a real system.
Keep the escape hatch to Excel
Staff know Excel and some tasks are genuinely better in it. The system should export easily rather than trying to prevent it. This makes the transition considerably smoother.
System components
| Component | Role |
|---|---|
| Master data | Customers, products, staff, suppliers — the shared foundation |
| Core business workflow | The company-specific part, where most development effort goes |
| Role-based permissions | Who can see and edit what — needs careful design from the start |
| Audit log | Who changed what and when; settles most internal disputes |
| Reporting and export | Replaces the manual month-end consolidation |
| Excel import | Migrates historic data and keeps accepting partner files |
Phased delivery
Six to eight weeks per phase, each ending with something genuinely usable rather than a demo.
- Phase 1: Master data and the single most important workflow. One department using it for real.
- Phase 2: Remaining workflows, full permissions, rollout across the company.
- Phase 3: Reporting, automating remaining manual steps, integration with other systems if needed.
You retain the right to stop after any phase. This belongs in the contract, and it is the best protection a buyer has.
The hardest part is not the coding
It is cleaning the legacy data. Ten years of spreadsheets produce customer names spelled three ways, phone numbers in every format, duplicate records. The new system has stricter constraints and will reject them. Budget time for this at the start, not when migration day arrives.
What you would need to provide
- Copies of the spreadsheets in use, with an explanation of how they link
- Someone internally who understands the process and can give regular time to the project
- The list of reports currently produced by hand each month
- A decision on which workflow matters most, to build first
Written from the team's hands-on experience delivering infrastructure and software. No sponsorship, no product placement.