Dynamic Scaffolding Configuration & Ordering Platform
Rule-driven configuration, live material take-off generation and multi-role ordering.
Role
Senior Frontend Engineer — configuration engine & ordering flows
Engagement
Full-time at Segwitz
Client
Industrial scaffolding supplier
Period
2024 — 2025
The problem
Scaffolding orders were assembled manually: a customer described a structure, someone with domain knowledge worked out which standards, ledgers, boards and couplers were needed, and priced it in a spreadsheet. The process didn't scale, was error-prone, and gave customers no visibility into what they were actually buying. The product needed a configuration engine that encoded expert rules and produced an accurate material take-off on demand.
My responsibility
Owned the frontend of the configuration and ordering experience across all three roles: the rule-driven form engine, the live MTO computation and preview, saved-configuration state, and the checkout/order workflow that hands off to finance.
Surfaces shipped
Super Admin
Defines the configurable product catalogue: component rules, compatibility constraints, pricing, tax, stock and the templates members configure against.
Member
The configurator itself — dimensions, structure type and constraints drive a live bill of materials, saved configurations and checkout.
Finance
Order, invoice, payment and credit workflows tied back to generated MTOs, with approval states and export.
Architecture
How it was structured, and the reasoning behind each boundary.
- 01
Rule-driven form engine
Fields aren't hardcoded — Super Admin defines configuration parameters, constraints and dependencies, and the Member UI renders and validates them dynamically. Adding a new product family is a data change, not a release.
- 02
Derived MTO state
The material take-off is treated as a pure derivation of configuration inputs. Inputs live in a Zustand slice; quantities recompute through a memoised selector pipeline so the preview stays in sync without a server round-trip on every keystroke.
- 03
Server-authoritative pricing
Client-side numbers are an estimate for responsiveness; the server recomputes quantities and pricing at checkout. The UI makes the authority boundary explicit so nobody ships on a stale client calculation.
- 04
Role-scoped routes and navigation
Super Admin, Member and Finance share an app shell but resolve navigation, guards and action availability from a single role model — no duplicated permission logic per screen.
- 05
Order lifecycle state machine
Draft → quoted → ordered → approved → invoiced → fulfilled, modelled as explicit states. Every screen reads from the same machine, which removed a family of 'impossible status' bugs.
Key challenges
- 01
Encoding domain expertise in constraints
Scaffolding compatibility rules live in people's heads. I worked through them with domain experts, turned them into declarative constraint data, and built a validation layer that explains *why* a configuration is invalid — not just that it is.
- 02
Live computation without UI jank
Recalculating a full bill of materials on every input change is expensive on large structures. Selectors were scoped per component family and results memoised, keeping interaction latency well inside a frame budget.
- 03
Three roles, one mental model
Finance sees an order that Admin configured and a Member placed. Keeping IDs, versions and snapshots consistent across those views meant treating the order as an immutable record with references rather than a mutable shared object.
- 04
Checkout that tolerates change
Configurations get edited mid-flow. The checkout re-validates against the current rule set and surfaces a diff of what changed before committing an order.
Implementation
- 01
Started with the data model, not the screens
Configuration, constraint, component, MTO line and order were defined as types first. The UI then became a rendering of that model, which is what made the dynamic behaviour tractable.
- 02
Built the configurator as a composable primitive
One field renderer handles numeric, select, boolean and grouped inputs with constraint-aware disabling and inline reasoning, reused across every configuration template.
- 03
Made the MTO readable
A bill of materials nobody can read is useless. Grouping by component family, subtotal rows, unit clarity and export were treated as core requirements, not polish.
- 04
Tested the maths
Quantity derivation is covered by unit tests with real structure scenarios, because a wrong count is a wrong delivery on a construction site.
Results
3
Role-based surfaces
Dynamic
Configuration engine
Live
MTO generation
- 01Configuration that took an expert with a spreadsheet now happens in-product, with an itemised material take-off generated instantly.
- 02Super Admin can introduce new configurable product families without an engineering release.
- 03Order, approval and invoicing share one lifecycle model across Member and Finance, removing manual reconciliation.
- 04Constraint validation catches invalid structures before they become an order, instead of after they become a delivery problem.
Technologies
- Next.js
- TypeScript
- Zustand
- React Query
- Tailwind CSS
- React Hook Form
- Zod
- Node.js
- PostgreSQL
- Jest
Technical highlights
- Declarative constraint engine driving dynamic form rendering
- Memoised MTO derivation from configuration state
- Explicit order lifecycle state machine shared by three roles
- Client estimate / server authority pricing boundary
Building something similar? I’d like to hear about it.
Start a conversation