What a bill of quantities taught me about components

Before I wrote React for a living, I was trained to write bills of quantities. It took me an embarrassingly long time to notice that I had been doing the same job in both places: breaking a large, messy thing into small, described, countable parts so other people can agree on it.

Agree the rules before you measure

No surveyor measures a building from scratch with their own private rules. In Nigeria we work to a standard method of measurement (BESMM), and elsewhere you will see NRM or CESMM. The method fixes the units, what gets measured as a separate item, and how things are described. It means my bill and yours can be compared line by line.

Design tokens are the frontend version of this. Spacing, type sizes and colours are agreed once, named, and then everyone measures against them. When a team skips this step, you end up with fourteen slightly different greys and nobody can say which one is right.

Describe once, reference everywhere

A good bill does not describe a concrete mix in full every time it appears. It describes it properly once and every later item refers back to it. Components work the same way. A Button is described once, with its states and rules, and the rest of the app refers to it instead of restating it.

Preliminaries are real money

The preliminaries section of a bill covers things nobody admires in the finished building: site setup, insurance, temporary works, supervision. They are still a real share of the cost, and leaving them out is how estimates go wrong. In software, preliminaries are loading states, error states, empty states, focus styles, build tooling and tests. Clients rarely ask for them. Users notice immediately when they are missing.

Provisional sums for the known unknowns

When part of a design is not ready, a bill carries a provisional sum: an honest placeholder that says "something goes here, and this is our best allowance for it". Frontend has the same tool, it just goes by other names. A skeleton screen, a feature flag, a stubbed API response. The trick in both trades is to make the placeholder obvious, so nobody mistakes it for the final thing.

Structure decides what change costs

The real test of a bill is not the tender. It is the first variation. If the items are well structured, pricing a change is a short calculation. If they are not, every change becomes a negotiation. The same is true of a codebase. A well-structured component makes the next change cheap. A tangled one makes every change a small project.

I like to think the two trades keep each other honest. The BoQ habit makes me want every part of an interface counted and described. The frontend habit makes me impatient with any process that cannot be changed quickly.