I work somewhere between technology, design and delivery.

I like understanding the whole problem before deciding what needs to be designed, built or changed.

I’ve spent most of my career building things for the web, but the job has gradually become less about writing code and more about making good decisions. I’m comfortable moving between strategy and implementation: talking to stakeholders, interrogating a brief, sketching an interface, working through technical architecture, writing code, reviewing somebody else’s work or figuring out how we actually get something shipped.

Start with the problem

I’m not particularly interested in technology for its own sake. Before choosing a platform, framework or approach, I want to understand what we’re trying to achieve, who it’s for and what constraints we’re working within.

Sometimes the right answer is a bespoke application. Sometimes it’s a well-configured existing platform. Sometimes it’s changing a process rather than building anything at all. I’d rather find the simplest good solution than create unnecessary complexity.

Design and development belong together

I’ve always worked across design and development, and I think being able to move between the two makes both better. Technical decisions affect the experience and design decisions affect how something needs to be built.

I like getting developers involved before designs are considered finished and treating prototypes as a way of thinking, not just demonstrating. The best solutions usually emerge through iteration between design, technology and content rather than being passed from one discipline to another.

Make things, early

I prefer working software to lengthy descriptions of working software. Once we understand the direction, I like to get something tangible in front of people quickly.

That might be a rough prototype, a small technical proof of concept or the simplest version of a feature. It gives everyone something concrete to respond to, exposes assumptions early and tends to produce much better conversations than trying to resolve everything in documents and meetings.

Keep the technology boring where it should be

I enjoy experimenting with new technology, but production systems aren’t experiments. I favour established patterns, understandable architecture and as few dependencies as the problem reasonably allows.

Complexity has a cost long after something launches. The cleverest solution today can easily become somebody else’s problem in two years, so maintainability, performance and the ability for another developer to understand what I’ve done matter to me.

Use AI as leverage

AI has become part of how I research, prototype, develop and explore ideas. Used well, it dramatically reduces the distance between having an idea and being able to test it.

I don’t see that as a reason to remove people from the process. Quite the opposite. The value increasingly sits in knowing what to ask, recognising what is good, spotting what is wrong and understanding enough about the underlying problem to make the final decision.

I’m interested in using AI to remove repetitive work and increase the amount of time people can spend thinking, designing and solving harder problems.

Ship, measure, improve

Launching something isn’t the end of the project. Real users have a habit of exposing things that workshops, prototypes and test plans don’t.

I like putting useful measurement in place, watching how something behaves and using that evidence to decide what happens next. Not everything needs continuous optimisation, but important decisions should be informed by what people actually do rather than what we assumed they would do.

Leave things better than I found them

Good delivery isn’t just getting the immediate piece of work over the line. I want the codebase, process and team to be in a better position afterwards.

That can mean simplifying architecture, documenting an awkward decision, improving tooling, removing technical debt or helping somebody understand something they didn’t before. The best work creates momentum beyond the thing that was originally commissioned.