About

I have been building websites since 2012, which in this industry is roughly three careers ago. I started with promotional pages for my band back when Myspace was the center of the internet and everyone was learning HTML whether they meant to or not. That was my introduction to CSS as well, and to the particular satisfaction of fixing something by understanding it rather than by guessing at it.

Since then I have built sites for a wide range of clients — solo professionals and artists, in-house teams, and mid-size businesses — and the work has changed enormously while the fundamentals have barely moved at all. That gap is most of what this page is about.


The line between design and strategy

There is a thin and frequently crossed line between being a website designer and being a marketing specialist or business strategist. I want to be clear about which side of it I work on.

I build websites. I do not write your marketing plan, and I do not set your business strategy. What I can tell you, from having watched a great many sites succeed and a greater number quietly fail, is that a website’s success depends far more on the plan behind it than on the design of it. A beautifully designed site with no clear audience, no obvious next step, and no reason for anyone to return will underperform a plain site that knows exactly what it is for. This is not a comfortable thing for a designer to say, but it is true, and saying it early saves everyone a great deal of money.

So the ideal is that we build on top of a marketing plan and business strategy that already exist and already cohere. If you have those, the website becomes a translation exercise — taking what you know about your clients and making it legible to them. If you do not have them yet, the honest recommendation is to sort that out first, and I will say so rather than build a site that looks confident about things you have not yet decided.

I can help with the website expression of a strategy. I cannot substitute for the strategy itself, and I would not pretend otherwise.


What AI changed, and what it did not

AI can build websites now. Not badly, either — it can produce something that looks like a website in an afternoon, and for a certain kind of site that is genuinely enough. Pretending otherwise would be silly, and I have watched enough of this industry to know that the people who insist a new tool is irrelevant are usually the ones the tool replaces first.

What AI changed is the cost of producing a first draft. What it did not change is everything that happens after the draft: deciding which decisions are expensive to reverse, recognizing that the theme you picked will fight you in month four, understanding why a form should notify two addresses instead of one, and noticing when it quietly stops notifying anyone at all. It did not change the maintenance problem, which is where most websites actually fail — not on launch day, but in the eighteen months after, when nobody is watching.

The other thing it did not change is judgment about people. A site is built for a specific audience, and understanding that audience is not a code problem. It is a listening problem, and it is the part of the work I still find most interesting after more than a decade.

I use AI in my own work, for the parts where speed costs nothing. It makes me faster. It does not make me unnecessary, and the clients who are happiest are the ones who understand the difference.


How I got here

I studied electrical computer engineering before I did this. That background left me with a habit that has served me well ever since: when something is not working, I assume the problem is structural until proven otherwise. Most website problems are not mysteries. They are a small number of ordinary causes with a thin layer of confusion over the top, and the work is to find them methodically rather than to try things until something sticks.

When I moved into web work, I explored the three main CMS options properly — Drupal, Joomla, and WordPress — rather than picking the one with the most enthusiastic blog posts. Drupal is powerful and unforgiving. Joomla sits somewhere in the middle. WordPress won because it struck the best balance between capability and the ability of a client to actually use the thing after I hand it over. That last part matters more than it sounds. A site the client cannot update is a site that will be out of date within a year, no matter how well it was built.

I have worked primarily with WordPress since, and the tool has grown into something far more capable than it was when I started. The reasons I chose it in the first place have held up.


How I work

Hands-on, which means the person you talk to at the start is the person building the site at the end. No account manager relaying messages, no offshore team you never meet. I take a genuine interest in whether the thing works for you, not just whether it launches on time, and I will tell you when something you have asked for is not worth the money.

I am also direct about scope. Projects go wrong most often at the edges — an assumption here, an exclusion there — and naming those boundaries early is the cheapest form of project management there is. You will always know what is included, what is not, and what it will cost before any work begins.


Who I work with

Clients who want a credible site without a full custom-design budget, and who are prepared to be honest about what their website is for. That is a broader group than it sounds. I have built for solo practitioners, artists, small firms, and in-house teams at mid-size companies, and the ones who get the most out of the process are the ones who arrive with a clear idea of the problem rather than a clear idea of the design.

If you are not sure where you fall, a consultation is the cheaper first step. We talk about what you have, what is not working, and whether you need a build, a fix, or simply a plan. You will leave with a straight answer, even if the answer is that you do not need me.