01 / Discipline
Web Development
Interfaces engineered as systems, not pages.
A website that is a set of pages costs more with every page. A website that is a system costs less.
The tenth screen should cost less than the first.
Most sites get more expensive as they grow. A new page means new markup, new styles, a new set of decisions about spacing and states, and a new place for the design to drift. Six months in, nobody can change the button without checking eleven templates.
We build the other way round. The components, states and rules come first, and the pages are assembled from them. The work front-loads, and then it compounds in your favour instead of against you.
What that means in practice
Six things this discipline actually does.
- 01
Design systems
Tokens, components and states defined once and used everywhere, with the rules written down rather than held in someone's head.
- 02
Component engineering
Accessible, composable interface primitives that behave correctly under keyboard, screen reader and slow network before they behave beautifully.
- 03
Performance budgets
A number agreed before the build starts, enforced in CI, and treated as a requirement rather than an aspiration.
- 04
Motion and interaction
Motion used to explain state changes and spatial relationships - and removed entirely where it only decorates.
- 05
Content modelling
Structures your editors can actually use, so publishing does not require a developer and the design cannot be broken by an em dash.
- 06
Accessibility
WCAG 2.2 AA as the floor. Semantics, focus order and reduced-motion paths built in, not audited in afterwards.
How it runs
Four stages, in this order.
The order is the method. Every stage produces something the next one needs, and skipping one means the stage after it is guessing.
- 01Ground
Constraints before pixels
What the business needs, what the traffic looks like, what has to survive two years of edits. The grid before anything sits on it.
- 02System
Build the vocabulary
Tokens, type scale, grid, components. Enough of the system to assemble any screen in the brief without inventing anything new.
- 03Assembly
Compose the screens
Pages come together from parts that already work. Review happens against real content on real devices, not against a flat mockup.
- 04Hardening
Make it survive contact
Performance budget enforced, accessibility verified with a keyboard and a screen reader, error and empty states designed rather than discovered.
Outcomes
What came out of it.
Sample figures from representative engagements. Not a guarantee, and not an average.
- 0.02
- Cumulative layout shiftMedian across recent builds
- 94
- Lighthouse performanceMobile, throttled, field-calibrated
- 3.4×
- Faster page assemblyAfter the system lands
Asked often enough to answer here.
Do you work with an existing design system?
Usually, yes. Where one exists we extend it and document the gaps rather than replacing it - a second system is almost always worse than an imperfect first one.
What does the performance budget actually cover?
Total transferred bytes per route, largest contentful paint on a mid-tier Android over a throttled connection, and interaction latency. It is checked on every pull request.
Which stack do you build on?
Whatever the constraints point at. Content-heavy marketing sites are usually static-first; application surfaces are not. We pick after the discovery, not before.
Rarely on its own