How we build, and what our words mean.

1. 1

   Research before design

   We capture your current site if you have one, read what your competitors actually rank for, and look at how customers describe the problem you solve. This happens before anything visual, because a layout decided before the content is known is decoration.

2. 2

   A written brief you approve

   What the site needs to do, who it is for, what each page is responsible for, and what success looks like — agreed in writing before a line of code exists. If the brief is wrong, everything downstream is wrong, and it is far cheaper to argue at this stage.

3. 3

   A free prototype, before you pay

   We build a real working version of your homepage and send it to you. Not a mockup, not a template with your logo dropped in — a live page you can open on your phone. You decide whether it is worth paying for after you have seen it, which is the opposite of the usual order.

4. 4

   Build on a static foundation

   Pages are pre-built and served as files rather than assembled by a server on every request. That is most of where the speed comes from, and it removes the database and admin login from the request path, which is most of where the security comes from. Pages that need to change on a schedule use incremental regeneration.

5. 5

   Accessibility as we go, not as an audit at the end

   Contrast, focus order, alt text, keyboard operation and heading structure are checked during the build against WCAG 2.2 Level AA. Retrofitting accessibility after launch costs several times more than building it in, and usually produces a worse result. Our own gaps are listed on the accessibility page.

6. 6

   Measured on real visitors, then handed over

   After launch we watch field data, not just lab scores — see below. You get the domain, the hosting account and the code in your own name, because a site you cannot leave with is a hostage, not an asset.

There are two kinds of performance data and they routinely disagree. Almost every “we build fast websites” claim quietly relies on the flattering one.

We use Lighthouse during the build because it is fast to run and catches obvious mistakes. We judge the result on field data, because that is what your customers experienced and what search engines act on. When we report on a site's speed, we will tell you which one we are showing you.

The absence of these is deliberate, and you should be suspicious of anyone who offers them:

• A guaranteed position in Google. Nobody can guarantee this, because nobody controls the ranking system. Anyone promising a number-one spot is either misunderstanding their own product or counting on you not checking.
• A specific percentage lift in sales or conversions. We have no way to know your close rate, your margins, or what else changes in your business the month we launch. A figure we cannot attribute is a figure we will not quote.
• A perfect 100 Lighthouse score. Achievable, and often achieved by removing things your customers needed. We optimise for the field metrics that affect real visits, not for a screenshot.
• “ADA compliant.” There is no certification that makes a private business website ADA compliant, and no plugin that delivers it. We build to WCAG 2.2 AA, tell you where the gaps are, and are clear that this is a technical standard rather than legal advice.

None of the above is worth anything as a promise on a page. What makes it checkable is that the writing follows published editorial guidelines, mistakes are logged on a public corrections page rather than quietly edited, and every claim in the glossary links to its primary source so you can go check it yourself.