We build the boring web.

A small business in Camden has paid for its website three times in five years. Different agency each time. Each one explained that the last build was tired, fragile, or built on the wrong thing. Each rebuild took three months, cost more than a small car, and produced a site that looked broadly the same to anyone actually visiting it. The third agency has now stopped returning emails.

This is not unusual. It is the default. An entire industry runs on the idea that a business website is something you keep replacing — that the framework world has moved on, that the design is "looking dated", that the codebase is too old to maintain. Every two years, someone with a deck shows up to tell the owner it is time to start again. It is rarely true. It is almost always expensive.

what we mean by boringNot basic. Not slow. Settled, on purpose.

Boring is not refusing to use new things on reflex. It does not mean grey designs and tired fonts. It does not mean dragging plain HTML around with a text editor and telling the client they cannot have nice things. People hear "boring" and picture sites built by people who do not enjoy their work. That is not what we mean.

Boring means the unfashionable choices, made deliberately. It is the framework that has been around long enough to be unfashionable. It is the database every backend engineer can read on a Tuesday. It is the deployment pipeline that fits in eight lines of config. It is the stack where the worst bug you will ever see has already been filed, fixed, and written about three times. Boring is what is left when you stop choosing for novelty and start choosing for survival.

why this is the high-skill choiceAnyone can chase. Choosing is the work.

Anyone can chase the framework that shipped last month. The marketing has already been written. The blog posts already exist. Picking it requires only the willingness to be wrong about it later, on someone else's money. That is not a hard skill. That is the easy direction of the same conversation.

The hard part is choosing the boring tool when the boring tool is right, and naming the moment it isn't. That requires judgement. You have to know how the old thing fails. You have to know what the new thing has not yet been tested against. You have to know what the customer's three-year horizon looks like, and you have to be willing to argue for it when the brief asks for something shinier. We have moved on from boring tools when they failed us — when the queries got slow, when the runtime was abandoned, when the workflow could not survive a third engineer joining the team. None of those decisions felt brave. They felt overdue.

The bar a new tool has to clear is short. It must solve a problem the boring option does not. Its failure mode must be survivable for the client. It must still be maintained in five years by people we have never met. Most new tools fail the first question, quietly. The ones that have cleared all three got used. TypeScript was one — for a long stretch it looked like a Microsoft hobby and we ignored it. By the time half the JavaScript ecosystem had quietly converted its public APIs to it, it had crossed the bar. We adopted it. It was not interesting by then, which is exactly when we wanted it.

why this matters for a small businessThe protections only show up over time.

A small business does not care about our stack opinions. The owner of a six-person accounting firm has never had a conversation about edge runtimes and never will. What she cares about is that the site is up when a new client looks her up on a Tuesday morning, that the bill at the end of the year is not a surprise, and that if the agency she hired closes its doors, the next person can pick up where they left off. Boring delivers all three.

A site built on settled tools still works in three years, because settled tools still work in three years. There is no migration to do, no framework version to chase, no quarterly invoice for "platform updates". A site that loads quickly on a phone with poor signal costs almost nothing to host, because most of the work was already done by the time anyone visited. A site whose code looks like every other site of its kind can be handed to any reasonable developer, anywhere, and they will recognise it within an hour. The lock-in problem solves itself when you refuse to build anything anyone could be locked into.

None of these are technical luxuries. They are commercial protections, and they only show up after years have passed. The agency that built her site might still be around in 2031. It might not. The point of the boring stack is that it does not matter either way.

what we refuse to buildThree lines we won't cross.

We won't ship a single-page application for a five-page brochure site. The browser already does navigation. Replacing it with a fragile JavaScript imitation, so the site can feel "app-like" to a visitor who stays ninety seconds, is a tax we are not willing to charge a client.

We won't put a database behind a site that has no need for one. A page listing your services, your prices, and a way to contact you does not require a CMS, a content lake, or a query layer. It requires a file. The version of this work that gets sold as "future-proof" is, in practice, a maintenance contract dressed up as architecture.

We won't take on a project where the success criteria is a redesign on a two-year cycle. If something on the site stops doing its job, we will fix the thing that stopped working. If the brand changes, we will rebuild the parts the brand change actually touches. We will not bill a client to redo a site that is still doing what they hired it to do, and we will say so when they ask.

closeWhat a website is worth.

The site we build is not the one that wins a design award this season. It is the one still standing on a Tuesday in 2031 — loading in under a second, costing almost nothing to run, and being read by the customer you needed it to reach. That is what we mean by boring. That is what we think a website is worth.