There’s always a better way to build something

18 January, 2025

There’s always a better way to build something

One aspect of building things – software, systems, anything complex – that I’ve grappled with is the tension between the path taken and the potentially ‘better’ path not taken. There’s nearly always a theoretical improvement possible, an alternative approach that might seem better in retrospect.

My past tendency was often to try and anticipate this, to aim for a near-ideal architecture or solution from the outset. I’ve realised this pursuit of the ‘best’ way can hinder simply getting started and making progress. What seems more effective, I’m finding, is identifying a credible, viable pathway – one that addresses the core needs – and committing to it, accepting it might not be the ultimate solution.

Considerations like future scalability and resilience have to be woven in. Where the balancing act gets particularly tricky, in my experience, is with technology choices. The allure of the ‘bleeding edge’ is strong; the promise of new capabilities or efficiencies is tempting. Yet, I’ve learned – sometimes the hard way – that adopting nascent tech carries significant overhead in terms of risk, unexpected behaviour and integration challenges. Often, a more pragmatic choice involves leveraging established, well-understood technologies, even if they feel less cutting-edge (emphasis on feel). It’s a trade-off between the potential of something imaginary and the stability of something real.

Then there’s the inevitable hindsight. That moment during or after a build where you think, “Ah, perhaps if I’d used thatcomponent, or structured it this way…”. It’s easy to get caught in that loop. But I try to temper this by remembering that the ‘better way’ perceived in hindsight might ignore crucial details or unforeseen complications that would have arisen along that path instead. One or two unexpected issues, those ‘curveballs’, can fundamentally alter the viability of any approach.

So, for me, the practical path forward involves accepting a ‘good enough’ direction initially, building with key future-proofing principles in mind (like scalability), making pragmatic technology choices based on stability as much as features, and resisting the paralysis of hindsight by acknowledging the hidden complexities inherent in any challenging build. It’s about progress over perfection, and navigating the details as they come.

I've been building tech for over 11 years. Made ONFORM and Campaign Pro as owner of Going Bold. Lead the team behind the FAW ecosystem. Work at Hopp Studio - helping to grow a digital agency.