01
Building for the internet
I started programming in 1996, when the web felt small, strange and full of unfinished possibilities. The tools have changed many times since then, but the underlying attraction has stayed remarkably consistent: a computer, a collection of ideas and the ability to make something that other people can use.
My professional work now centres on frontend architecture and technical leadership. I spend a lot of time thinking about how platforms evolve, how teams make changes safely and how technical choices shape the experience of both users and developers.
02
How I think about software
Architecture should reduce complexity, not relocate it.
I design systems that remain understandable, maintainable and adaptable while products, teams or technologies evolve. AI can multiply and accelerate the work, but traditional human engineering judgement, context and clear standards should remain essential.
I’m less interested in architecture as a fixed diagram than in what it makes possible: predictable changes, useful boundaries, clearer conversations and room to learn without rebuilding everything at once.
03
Curiosity and experimentation
I have always tried to be on the edge of technology: playing with new technologies, merging them in combinations that don’t already exist, and using the latest techniques and optimisation practices to give people genuinely engaging experiences.
I still enjoy trying unfamiliar tools, studying interaction and following the web platform as it grows. Some experiments become production ideas; others are simply a way to understand a new constraint or rediscover an old technique.
This site is where I collect that work: projects, technical essays, field notes and, over time, smaller experiments that do not need to become formal case studies.
04
Planning and putting in the work
I’m not only a frontend architect on paper. I’ve worked with enough different people, companies and technologies to know that no two projects follow the same path. The teams, the tools and the constraints change every time, and the work is always dynamic. What I try to keep constant is the discipline of planning and delivering it properly, so stakeholders, project managers and engineering managers stay genuinely in the loop rather than finding out after the fact.
- Communicate
- Collaborate
- Research
- Prototype
- Plan
- Estimate
- Develop
- Document
- Test
- Deploy
The experience has taught me how to build strong relationships with every department in an organisation, which is usually where the real success comes from. Within my own department I like to lead the development phase, but I can just as easily work alongside, above or under others on projects of any size or complexity, as long as we’re dedicated to creating something beautiful together.
05
Away from the screen
I live on the Gold Coast and surf regularly. Time in the ocean, including the occasional surf trip, is a useful contrast: a mildly meditative state that lets me pause and reflect out on the blue, and come back more aware in how I think professionally about design systems and technology.
Rather than fighting the waves into behaving the way I want them to, I take them as they come and shape myself around them, working with the ocean instead of against it. That is what builds the attention, the patience and the willingness to adapt to conditions that will not cooperate with a plan.
Engineered Coast, the name I gave all of this, reflects both sides of that life: technical precision and movement, architecture and weather, the terminal and the ocean.