About
Most website problems sit between teams. That’s where I work.
On a typical company website, the tracking sits with marketing, the template with the developers, the copy with an agency and the booking form with a vendor. Nobody owns the drop-off. I work in that product layer between marketing and engineering, taking a problem from the first sign of it in the numbers to a fix in production.
I think about a website the way a product owner would: every page has a job to do for the business, and a change earns its place by helping the page do that job. I’m as comfortable in the strategy conversation as in the pull request. Often that means I diagnose the problem and build the Shopify section or landing page that fixes it, which cuts out a round of handover.
Recent work has included live multi-market sites built on legacy templates and shared with agencies and internal teams. I use AI coding agents to get from diagnosis to a shipped change faster, and I review their work the way I’d review any other contributor’s.
See the workHow I like to work
- Commercial before aesthetic
- A page is judged on whether it moves enquiries or sales. How it looks matters when it helps with that.
- Audit before acting
- I check the data and what’s already built before proposing anything. The cause is usually smaller and more specific than a redesign.
- Hypotheses, not hunches
- Every change starts with a reason it should work and a way to tell whether it did.
- Build it or brief it
- If I can build the change, I do. If an agency or developer owns that part, I write a brief they can build from without a meeting to decode it, then stay with it through sign-off.
- Language is a detail
- I pick up whatever the site is built in. The concepts carry over; the syntax is the easy part.
- Reusable over one-off
- Fixes become components and templates, so the next page inherits the fix instead of repeating the problem.
- Plain about outcomes
- If there’s a number, I’ll show where it came from. If there isn’t, I’ll describe what changed and leave it there.
Capabilities
Grouped by the problem they solve.
Optimisation
The traffic is there. The enquiries and sales aren’t.
- Conversion rate optimisation
- Hypothesis development and experiment design
- Funnel analysis
- Behaviour analysis
Product & UX
People can’t find the next step, or don’t trust it enough to take it.
- Customer flows
- Information architecture
- Booking and enquiry forms
- Landing pages and lead capture
- Conversion copy
- Mobile UX
Implementation
The fix is agreed, then sits in someone else’s backlog.
- Working in whatever the site runs on: Shopify, WordPress, HubSpot or a static build
- HTML, CSS and JavaScript
- Liquid, PHP and Astro for templates and themes
- Bash, Python and SQL for tooling and data fixes
- Reusable CMS and theme architecture
- Integrations and tracking coordination
Measurement
Decisions get made on numbers nobody fully trusts.
- GA4
- Google Tag Manager collaboration
- Hotjar and behaviour analytics
- HubSpot forms and funnel integration
- Attribution and tracking requirements
Search & discoverability
The pages that should rank don’t, or they rank for the wrong intent.
- Technical and on-page SEO implementation
- Schema and structured data
- Internal linking
- Content architecture
Tools
Tools come second.
These are the ones I use most. The capabilities above matter more: tools change, and most problems on a website aren’t caused by a missing one.
- Platforms
- Measurement
- Languages
- Also