3D printing & additive manufacturing
UK’s largest 3D printing service
Designed and built a manufacturing ERP from nothing, covering the full commercial and production path — quoting, orders, scheduling across the machine floor, and dispatch — for the UK’s largest 3D printing bureau.
- Role
- Lead engineer, in-house build
- Stage
- Enterprise / manufacturing group
- Sector
- 3D printing & additive manufacturing
Outcomes
- Full ERP built from scratch
- 0 → 1Full ERP built from scratch
- Machine floor under management
- £2MMachine floor under management
- End-to-end process covered
- Quote → dispatchEnd-to-end process covered
- Shipped against a live factory
- Phase 1Shipped against a live factory
Context
A high-mix, low-volume additive manufacturing business: many small orders, each with its own geometry, material, machine, and lead time. Off-the-shelf ERP assumes repeatable production runs, which is the opposite of how a printing bureau actually works, so the commercial and production process was running on spreadsheets and institutional knowledge.
The problem
Model a production process where almost every job is bespoke. Quoting depends on part geometry and machine time rather than a price list; scheduling has to reflect which machines can run which materials; and the whole path from enquiry to dispatch needed to become traceable without slowing down the people currently doing it by hand.
- 01
Built the ERP end to end from zero
Quoting, order management, production scheduling, and dispatch as one system, replacing the spreadsheet-and-memory process the business had grown on.
- 02
Modelled the machine floor as a scheduling domain
Machine capability, material compatibility, and job duration as first-class concepts, so scheduling reflected what the floor could physically run rather than an idealised production line.
- 03
Reactive backend for concurrent production workloads
Spring WebFlux over MongoDB — a non-blocking stack and a flexible document model, chosen because part specifications vary enormously between jobs and a rigid relational schema would have fought the domain.
- 04
Shipped in phases against a running business
Phase 1 scoped to the commercial path so value landed early, with production and dispatch following — the factory could not stop while the system was built.
Trade-offs
Every architecture is a set of things you chose not to have. These are the ones that mattered here.
Built rather than bought
Off-the-shelf ERP is the default answer and usually the right one. Here the high-mix, geometry-driven quoting model sat far enough outside standard ERP assumptions that configuration would have cost more than a focused build.
Document store over a relational schema
Part specifications differ per job in both shape and depth. MongoDB absorbed that variance directly, trading relational guarantees for a data model that matched the domain instead of flattening it.
Stack
- Java 17
- Spring WebFlux
- MongoDB
- React
- AWS