frontend
Why Specsavers Was a Fascinating First Project
Thoughts from the intersection of code, craft, people, and progress.
Big reach, tight constraints, and lots to learn.
A well-known brand brings scale, scrutiny and a large number of real users who will not care how elegant the component architecture is. That made Specsavers a fascinating first project: the constraints were practical, the reach was significant and every decision had consequences.
The useful question behind “Why Specsavers Was a Fascinating First Project” is what changes in the work afterwards. A sound idea should improve a real decision, not only give us a neat phrase for describing it.
This matters because small choices repeat. What feels harmless once can quietly become the normal way of working.
Optimise for the next decision
Engineering choices are rarely permanent, but they can make the next choice dramatically easier or harder. The useful question is not whether an approach is perfect. It is whether it leaves the team in a good position when reality changes.
I look for feedback loops, visible trade-offs and a cheap route back. Small releases expose assumptions while they are still affordable. Clear defaults reduce accidental variation. A little discipline early is usually kinder than a rescue project later.
The best technical decision often buys clarity before it buys capability.
A practical way to start
A few questions help me decide what to do next:
- Is the simpler option genuinely insufficient?
- Can somebody new explain the decision back to us?
- Have we left a safe and affordable route to revise it?
None of those questions produces an automatic answer. They do make the trade-offs visible, which is usually the point where a team can stop arguing from instinct and start making a decision together.
Good engineering creates options. It solves today's problem without quietly charging tomorrow's team an unreasonable fee.
The details will change from project to project. The underlying habit of paying attention travels well.