The problem
The client is a group of businesses in construction and mechanical and electrical contracting. Between them they had the usual accumulation: an estimating process held together by spreadsheets and an ageing desktop tool, a component catalogue nobody owned, project tracking in one place and job information in another, and no consistent way for staff to move between any of it.
The obvious answer — buy something — did not fit, because the estimating work is where the group's actual expertise lives. Generic software would have flattened the thing that made them competitive.
So the answer was to build, and the real problem was not any single application. It was that building eight of them one at a time, each from scratch, would have been unaffordable.
What I built
A platform first, then the applications on top of it.
The foundations are a shared component library consumed by every application, single sign-on so staff move between them without noticing a boundary, and shared product analytics so the group can see how any of it is actually used.
On top of that:
- Mechanical and electrical estimating — the group's core expertise, encoded
- AI-assisted tender analysis, so an estimator can get through a document set that used to take days
- A rewrite of a legacy estimating workflow onto the web
- Project management built for how construction projects actually run
- An owned component catalogue behind an API, rather than data the group merely had access to
- A staff operations hub for the day-to-day
- A marketing automation platform
Where it is now
Live and in daily use across the group. Seven of the eight applications were built between May and August 2026, on foundations laid earlier that year.
The commit counts give a sense of the weight: 4,017 on the project management application, 906 on the field job-sheet app, 702 on the estimating suite, 565 on tender analysis, 476 on the estimating rewrite, 459 on the operations hub, 390 on marketing automation, and 233 on the shared package library that all of them depend on.
That is the argument for the platform. Application eight cost a fraction of application one, because by then the authentication, the interface library, the deployment pipeline and the conventions were settled. Building eight products for one client is only possible if you stop treating them as eight products.