Start with the problem, not the page

Most website projects start with a list of pages: Home, About, Services, Contact. It feels like progress — you can see it, tick it off, hand it to a designer. But a list of pages is an answer, and nobody's asked the question yet.

We build websites for a living, and the single biggest difference between a site that changes something about a business and a site that just sits there looking fine is whether that question got asked first.

The question that comes before any page

Before we open a design file, we ask: what is actually slowing your business down right now?

Not "what do you want the site to look like." Not "what pages does your competitor have." What's the specific, named thing costing you time or money every single week.

For one business we worked with, it was this: every order came in through a WhatsApp message, and someone had to manually chase stock, confirm price, and copy the details into a spreadsheet before anything shipped. The business didn't need a prettier homepage. It needed the order itself to stop depending on a person being awake and available. So that's what we built — not a brochure site with an order button bolted on, but a flow that answered price and availability questions on its own and only pulled a human in when a human was actually needed.

Different business, different answer entirely: a 34-year-old wire manufacturer wasn't losing orders to a bad website — they weren't showing up online at all. Their problem wasn't conversion, it was existing in a search result in the first place. That's a different build, with a different first page, aimed at a different outcome.

Same starting question. Two completely different websites, because the thing slowing each business down wasn't the same thing.

Why the order matters more than the pages themselves

When the page list comes first, the site ends up describing the business instead of doing something for it. It can look completely finished — nice type, a clean grid, a contact form at the bottom — and still change nothing about how the business actually runs. The same enquiries land in the same inbox, get the same manual reply, and six months later someone says the website "isn't really working," without being able to say exactly why.

When the problem comes first, every page on the site has a job to do, not just a place on the menu:

• A page that answers the five questions you get asked by every single enquiry, so you stop typing the same reply.
• A form that collects exactly what you need to quote accurately, the first time, instead of a back-and-forth to get the missing detail.
• A path from "interested" to "booked" or "ordered" that doesn't need you personally online to close it.

A website is finished when the problem it was built for is smaller than when you started — not when every page on the sitemap has content on it.

How this actually runs, start to finish

This isn't a one-off discovery call followed by a generic build. It's the shape of every project:

We talk about what's slow, not what you want built. The conversation starts with your business, not a Figma file. Sometimes what comes out of it is a full website. Sometimes it's one landing page and a better enquiry form. Once or twice it hasn't been a website at all — the cheaper fix was elsewhere, and we've said so.

You get a fixed scope and a fixed price before a line of code is written. Once we know the actual problem, we quote against solving that problem — not an hourly estimate that creeps as "small additions" pile up. Most builds land in 2–3 weeks depending on scope and how fast we get content and feedback back from you.

We use AI to move faster, not to skip the thinking. Some of the code is written with tools like Claude — it's genuinely faster at CSS than either of us, and we're not precious about that. What it doesn't do is decide what your business needs or talk to you directly. Every build is reviewed by hand before it ships, and the decisions about what to build in the first place are never outsourced to a model.

The site keeps working after launch, not just on the day it goes live. You get 15 days of monitoring after launch, free, because the first two weeks are when a form breaks under real traffic or a tracking pixel turns out to be misconfigured — not six months in, when nobody's watching.

You own what we build. No lock-in, no mystery dependency on us being reachable to make a text change. If you want to take the code elsewhere on day one, you can.

If a previous site left you locked into one agency to make even a small text change, that's not how we build. Ask who owns the code before you sign anything — not just with us, with anyone.

The next step

If you're planning a new site or thinking about a redesign, skip the page list for a minute and write down one sentence: the single thing that's actually slowing your business down right now. Bring that to the first conversation, and we'll work backwards from it to figure out what, if anything, needs building.