Founder story

Why I built Sitewell after years of managing client websites the hard way.

I did not start Sitewell because I wanted to launch “a SaaS”. I built it because the same website maintenance and SEO jobs kept eating time in almost every client project, and the usual process was far too manual.

The problem I kept running into

Most small business websites are not broken in a dramatic way. They slowly drift. A plugin update is missed. A page title gets duplicated. An old service page still ranks for the wrong search. Internal links point to pages nobody wants to keep. None of this is difficult in isolation, but it stacks up fast.

As a developer, I could fix each issue. The frustrating bit was context switching: checking technical health, scanning for SEO gaps, writing improvement notes, then repeating that cycle across multiple sites every month.

Why traditional maintenance and SEO workflows felt inefficient

The standard setup was a patchwork of tools and spreadsheets. One tool flagged technical issues, another tracked keywords, and somewhere else sat a monthly report nobody used to make day-to-day decisions.

That approach can work, but only if there is enough time and enough margin to keep translating data into action. For smaller teams and owner-led businesses, that translation step is where momentum usually dies.

I wanted something more practical: fewer dashboards, clearer priorities, and tasks that map to real website improvements rather than vanity metrics.

What I wanted Sitewell to do differently

The goal with Sitewell was simple: make website upkeep and SEO execution easier to run consistently, especially for people who are busy doing everything else in the business.

In practice, that means surfacing the next useful actions, not just listing problems. It means making technical and content work visible in one place. It means treating SEO as an operating rhythm, not a one-off project.

It also means being honest about trade-offs. Sometimes the right move is to improve an existing page like this booking system page. Sometimes you need a broader rebuild and tighter software support. It depends on the site and the business model.

What I learned early

Building the product was only half the challenge. Explaining why the approach matters is just as important. That became very obvious when I tested outbound demand generation, which I wrote about in this 500 cold email breakdown.

If you are in a similar position

If your website work feels reactive and scattered, you are not imagining it. The issue is often process design, not effort. Start by identifying the few recurring fixes and content improvements that actually move enquiries, then systemise those first.

If you want help doing that in a practical way, feel free to get in touch.