Web design & development

Most websites are commissioned twice. Once as a design, from one supplier, and once as a build, from another — and the second one quietly decides what the first one actually meant. We do both, which removes the argument.

Who this is for

You have something to sell or explain, and the current site is not doing it. The symptoms are usually specific: your salespeople send a PDF because the site cannot describe the product; leads arrive and go cold; the team stopped updating it eighteen months ago because publishing anything means asking a developer.

Or you are earlier than that — pre-launch, with a product and no public face for it yet, and the first impression matters more than it will ever matter again.

Either way the work is the same shape: decide what the site has to accomplish, design something that accomplishes it, and build it so that changing it later is cheap.

What we actually build

Marketing sites — the public case for a company or product. Usually five to fifteen pages, a CMS behind the parts that change, and a design system underneath so the twentieth page does not need a designer.

Web applications — logged-in products with real state. Dashboards, portals, admin tooling, anything where the interesting problems are permissions, data shape and error states rather than page layout. The Magnus Academy student dashboard is this kind of work.

Rebuilds and migrations — moving off something that has stopped paying its way. WordPress that takes eleven seconds to load, a Webflow site that has hit its ceiling, a bespoke build nobody remembers how to deploy.

How we work

Design and engineering run in the same week rather than in sequence. That sounds like a scheduling detail; it is the whole method. When a designer and an engineer are looking at the same problem at the same time, the impossible ideas die on the day they are had rather than three weeks later in a handoff meeting. We wrote about why the handoff is where projects fail.

Practically, that means:

You see it in a browser early. Not a clickable prototype — the real thing, on a real URL, usually within the first two weeks. Opinions about a static mockup are cheap; opinions about something you can scroll are useful.

Weekly working builds. Every week there is a link, and it is further along than last week’s. No black-box month where you hear nothing.

A design system, not a stack of pages. Type scale, spacing, colour, the component set, the motion vocabulary. It costs a little more in week two and saves most of the budget by week eight, because the tenth page assembles itself out of parts that already exist.

What you get at the end

A repository you own, on a stack a competent developer can pick up. A CMS where the things that change are editable and the things that should not change are not. A design system documented well enough that the next person does not have to guess. And a deployment that runs on push, so shipping a correction is a two-minute job rather than an event.

We do not build sites that require us. If you want us on retainer afterwards we are glad to be there, but that should be a decision you make because the work is good, not because you are locked in.

On performance

Every studio says “fast.” What we mean by it is specific: Core Web Vitals are a ranking factor and a conversion factor, and most of the damage is done by images and third-party scripts rather than by framework choice.

So images go through a build-time pipeline that emits modern formats at the size they are actually rendered, everything is dimensioned so the layout does not jump while it loads, and any analytics or chat widget gets weighed before it goes in. This site is the demonstration — the whole of it, every page, every image, is a few hundred kilobytes.

That matters more here than it does in London or New York. A large share of your audience is on mobile data on a network that is not always good, and a four-megabyte page is a bounce before anyone has read a word.

What it costs, roughly

Price tracks the number of distinct states the software has to be correct in — not the length of the feature list. Two kinds of user is nearly twice the work of one, because permissions then have to be decided everywhere instead of nowhere. Integrations with systems you do not control are routinely the most under-estimated line in any proposal.

We scope before we price, and we would rather tell you a project is smaller than you assumed than win it by agreeing with your number. Our CEO wrote the long version: what a web app actually costs to build.

When we are the wrong choice

If you need a five-page brochure site next week for the lowest possible price, a template and a competent freelancer will serve you better, and we will say so. If you need someone to execute a design that is already finished and signed off elsewhere, you are paying for half of what we do.

We are worth it when the design decisions are still open, when the thing has to be maintained for years rather than months, and when someone needs to hold both halves of the problem at once.

Tell us what you are building — even roughly. We reply to every serious enquiry within two working days, usually with questions.