I care more about the problem than the technology.

I came to this through websites. That is still where a lot of businesses first look for help, and I still build them. But working inside a real operating business, as a developer on the software it runs on day to day, made one thing obvious: the highest-value work usually happens behind the visible website.

The business I work in does not need “a developer” or “a website” as isolated things. It needs information to reach customers on time, staff to have the right screen in front of them, messages to send themselves, data to move between systems without somebody retyping it, and fewer mistakes at the points where people are busiest. Websites, internal tools, text messages, dashboards and automation are just different instruments for those jobs.

That is the model I bring to the businesses I work with. You should not have to diagnose the technical solution yourself. You explain what is slow, expensive or frustrating. I work out what would fix it and build that, and only that.

How I work

Problem first. The first conversation is about how customers find you, contact you, get a quote, book and hear back, and about what your staff do by hand to make that happen. Not about what I could build.

The smallest useful fix. Once we know where the leak is, I propose the least amount of software that plugs it. If it works, we look at the next one. Nobody should buy a system on day one.

Honest about what I control. We agree what success looks like before work starts. If I cannot deliver the system we agreed, I make it right. I do not promise outcomes that depend on your prices, your reputation or whether the phone gets answered.

Plain language. Every decision explained in words you would use yourself. If I cannot explain why something is worth doing, it probably is not.

Sometimes the answer is nothing. If the existing website is fine and the process behind it is fine, I will tell you, and you will have lost twenty minutes.