How I work
I work at the intersection of thinking and making. Understanding what a problem is actually about, then orchestrating the right pieces to solve it.
A few principles run through everything. I aim for simplicity, and I'm drawn to smart, lazy solutions: once you understand a problem well enough, you usually need less than you thought. Across 130+ client projects, personal builds, and years of freelancing, these six principles have shown up in some form every time.
Working with ambiguity
I'm drawn to the moment before things are figured out. When someone has a lot of ideas but no clear direction. When there's energy but also confusion. That's not a problem to fix quickly. It's a space that needs patience and structure.
One project involved a young CEO of a trades company. Full of ideas, constantly shifting direction. Every meeting brought new ambitions, and the team couldn't build on shifting ground. My role was creating space for him to explore ideas without derailing the project: translating vague excitement into concrete decisions, explaining trade-offs without judgment, and protecting the team from whiplash without shutting the client down.
Helping someone feel less lost is underrated work. It doesn't show up in metrics, but it's often what makes everything else possible.
Designing for real behavior
A lot of process design assumes ideal behavior: that clients will deliver content on time, that teammates will flag problems early, that everyone reads the brief. In practice, people are busy and doing their best. I'd rather design around that reality than keep insisting it should be different.
At the agency, we had a persistent bottleneck: clients not delivering content. The backlog grew, the team got frustrated, and the usual response was more reminders. The problem wasn't laziness. Websites just weren't the client's priority, and the process assumed they'd behave like project managers. I simplified the questionnaires, introduced time limits, and made it easy to pause and re-enter later. The backlog shrank.
Systems that guilt people into compliance rarely work. Accepting that attention is limited, and designing for it, tends to get better results than expecting discipline.
Understanding before solving
When something isn't working, the temptation is to look at the output. The design isn't good enough. The code has bugs. The client keeps changing their mind. But the real issue is usually upstream: someone doesn't have enough context, or the wrong question got asked at the start. This applies to internal collaboration and product thinking equally.
A designer on the team wasn't landing their work. The easy conclusion was quality. But they simply didn't have the context: no client calls, no access to internal discussions, incomplete briefs. I improved the briefing, added intent and background, arranged occasional calls. The work improved because the understanding did.
The same instinct applies when building for an audience. Most photography portfolio sites are designed with other photographers in mind, consciously or not. Asking "who is this actually for?" early enough, and letting the honest answer shape the structure, the language, and the decisions, usually produces something better.
Clarity before building
I'd rather ask one more question than discover halfway through that I was building the wrong thing. With clients, that usually means one more conversation before starting: the kind that surfaces assumptions neither side knew they were making.
Building a service directory with city and category filtering required working out the logic before any code was written. A plumber needs to be near you. A tax accountant working remotely doesn't. Getting those category-level rules established in advance meant the filtering worked correctly from the start, rather than being rebuilt once the edge cases surfaced.
For my own work, it means writing the brief before writing the code. Anticipated problems, rules established in advance, edge cases thought through. Not to eliminate surprises: those come regardless. A solid foundation doesn't make you rigid. It gives you something stable to adapt from when things don't go as expected, and that's what makes everything that follows faster.
Fresh eyes on hard problems
When you've been close to a problem for a long time, the closeness itself becomes the obstacle. You carry assumptions that feel like facts. Someone who hasn't been inside the same context can surface what you can no longer see.
A site I built wasn't getting indexed. The configuration looked correct, at least to the tool that helped build it. Using a different tool to crawl the live deployment with no prior context surfaced the actual redirect chains and where they broke. A third pass, from yet another tool with fresh eyes on the config files, fixed it. The problem wasn't technical complexity. It was that the original builder kept the original assumptions.
Knowing when you're too close is a skill. So is knowing who to bring in, and why a different perspective will find things you won't.
Building to understand
I have a bias toward making things. When a problem is clear enough, the most useful next step is usually to build something and see what happens. Planning has limits that only become visible once you start.
Uploading photography to a fine art site was tedious enough that I kept putting it off. So I built a small app to handle the repetitive parts. I mentioned it to someone recently, more or less as a throwaway detail. She was surprised that building an app would even occur to someone as a way to solve a personal problem. That reaction says something about where we are.
Some ideas also just need to wait for the right conditions. A service directory I designed as a prototype years ago sat untouched until the tools existed to actually ship it. When they did, I did. Building is a way of thinking. You learn things from making that you can't get from planning.
On technology
I use AI daily: for writing, building, thinking through problems, and gathering data. Different tools for different jobs. The split between them emerged naturally from noticing what each does well.
What interests me isn't the technology itself. It's how it lowers barriers: gives form to ideas, supports thinking instead of replacing it, and makes things achievable that previously required a full team.
The work I enjoy most is like conducting: you're not playing every instrument, but you're shaping how everything comes together. AI is genuinely good for that. It expands what one person can orchestrate without losing the feel for the whole.