Most business websites are slower and harder to change than they need to be, usually because the stack was chosen for the developer's convenience rather than the owner's.

What we build

Marketing and product sites, internal dashboards and tools, and web applications where the product itself lives in the browser.

How we think about it

Performance comes from restraint — not shipping a megabyte of JavaScript to render text. This site is a fair example: no framework, no runtime dependencies, self-hosted fonts, no third-party scripts.

Accessibility from the start. Keyboard navigation, sensible contrast, real semantics. Retrofitting costs several times more.

Content you can edit. If every copy change needs a developer, the site goes stale. It always does.

Built to be handed over. Boring, documented technology another developer can pick up.

Search and AI visibility

Increasingly the same job. Both classic search and AI answer engines reward structure — clean semantics, proper heading hierarchy, structured data, and content that stands on its own when quoted. We build that in rather than bolting on an SEO engagement afterwards.

What we push back on

Heavy frameworks where a static site would serve you better, and headless CMSs where a few markdown files would do. Not on principle — the maintenance burden lands on you, and unnecessary complexity is the most common regret in web projects. If you genuinely need the complex version we will build it.

What we actually build with

Static HTML where the content is static, which is more sites than the industry admits. A generator that turns markdown into pages, so writing a new article is writing a file rather than fighting an editor.

Where a site genuinely needs application behaviour — accounts, dashboards, data that changes per user — we build that, and we still keep the surface small. Server-rendered by default, JavaScript where it earns its place, and no framework adopted because it is the current answer to a question nobody asked.

The result is a site that loads fast on a mid-range phone over a poor connection, which is how a large share of the world browses.

A performance budget, agreed upfront

Performance is a decision made repeatedly during a build, not a pass at the end. So it gets a number at the start: a page weight ceiling, and Core Web Vitals targets that the site is measured against before launch rather than after complaints.

Practically that means images sized and served in modern formats, fonts self-hosted and subset rather than pulled from a third party, no analytics or tag manager loaded before content, and layout that does not shift as things arrive.

Third-party scripts are where budgets die. Each one is a request to a server you do not control, running code you did not write, on the critical path. We will push back on every one and lose some of those arguments, but you will at least know the cost.

Editing without us

Content that goes stale does so because updating it is annoying. So the editing path is decided early and honestly: for a small marketing site, markdown files in a repository are often genuinely enough. For a team of non-technical editors publishing weekly, that is the wrong answer and a CMS is worth its overhead.

The failure we design against is the one where every copy change becomes a support ticket. If that is the outcome, the stack was chosen wrong regardless of how modern it is.

Hosting and what happens after

We will host, or set you up to host, and either way the arrangement is documented and transferable. Deployment is a script you can run, not a ritual only we know. Domain, DNS, certificates and analytics all live in your accounts under your ownership.

Backups and rollback matter more than they get credit for. Being able to put yesterday's version back in a minute turns a bad deploy into an inconvenience rather than an incident.

Search, structure and AI answer engines

Both classic search and AI answer engines reward the same underlying thing: content that is well structured and stands on its own when quoted out of context.

That means real semantics rather than a page of nested divs, headings that describe an actual hierarchy, structured data that matches what a reader sees on the page, and answers written near the top of a page rather than buried after eight paragraphs of preamble.

We build that in during the work. It is substantially cheaper than an SEO engagement six months later that recommends rebuilding what was just built.