Loading
Product line
The built thing is a set of typed content models, a component library rendered on the server, and a performance budget enforced in the pipeline rather than measured after launch.
Website · in the build
Anatomy
The visible layer is the smallest part. These four decide whether the site is still good in two years or has quietly become a thing nobody dares edit.
The types of thing the site publishes, the fields each one has, and which of those fields are required. Settled before any page is built, because a model added later is a migration and a model guessed early is a permanent tax on every editor.
A finite library of section types — hero, split, index, ledger, media band — sharing spacing, type scale and surface tokens. Pages are composed from it rather than designed one at a time, which is why page fifty still looks like page one.
Static or server-rendered HTML with the critical CSS inline, images pre-encoded to AVIF and WebP at real widths, fonts subset and self-hosted, and third-party scripts either deferred or refused.
One canonical URL per page, per-page titles and descriptions, structured data only where it is truthful, a sitemap generated from the routes that exist, and internal links that make the hierarchy legible to a crawler.
Why it matters
The same artefact described above, read as outcomes rather than as engineering. Each one follows directly from a decision already explained on this page.
A performance budget checked on every commit means the site that launches fast stays fast, instead of quietly slowing down over the following six months.
Content held in a proper content model means updating copy, images or a page's composition doesn't require filing a ticket and waiting on a developer.
A real findability layer — canonical URLs, a generated sitemap, honest structured data — means new pages get found by search without a separate clean-up project later.
Enquiry forms verified end to end before launch mean a lead doesn't quietly vanish into an inbox nobody is watching in the site's first month.
Where a redesign replaces a site that already ranks, mapping the redirects first protects search visibility that took years to build rather than losing it on launch day.
Key features
Behaviour of the built thing, not a list of adjectives. Every entry below is something you can check after delivery.
A website and a web application are two different builds, and most quotes conflate them. This is the first one: pages that have to be found, read and understood by someone who arrived from a search result and will leave in four seconds if the first screen is slow. The artefact is a content model, a component set, a rendered page under a byte budget, and a person on your side who can change the copy without filing a ticket.
Technology
A stack we actually run in production. Where your team already has a preference and it is a reasonable fit, we work in yours instead of arguing for ours.
Runs on
Before we quote
The answers move a website quote by a factor of three, which is why a number given before them is not a number.
A website publishes: the content is authored, mostly the same for everyone, and the job is to be found and understood. A web application computes: users sign in, records change, permissions apply. Many briefs contain both, and the honest answer is usually to build the site first and the application as its own project, because they have different release rhythms and different risks.
A site one person updates twice a year and a site three people update weekly want different builds. Frequent editing justifies a content system with previews and roles; infrequent editing does not, and paying for one adds a subscription and a login nobody remembers. We size this to who will actually do the work.
If so, the URL structure and the redirect map are the first deliverable, before any design. A redesign that changes every URL without redirects loses accumulated search visibility, and that loss is slow to recover and hard to explain. We audit the existing URLs and map them before the new build starts.
Pricing and engagement
There is no fixed price for websites because the scope varies by the size of the content model and how often it needs editing — here is how the work is actually engaged, and which of these usually fits this product line.
For work where the requirements are genuinely settled. A written scope, a phased plan and a price we hold. Best for a defined build, a migration, a security engagement or a design phase.
Named engineers at a monthly rate, working on your board and in your repository. The right shape when the roadmap is still moving, which is most products after their first release.
Ongoing maintenance, monitoring response, dependency updates and a block of hours for changes, under a written arrangement agreed before launch rather than during an incident.
Where it is used
Sectors where we are asked for this artefact most often. It is a statement about the fit of the shape, not a client list.
How the work is run
This page describes the artefact. Scope, delivery model and engagement terms live on the service pages, which is where they belong — follow whichever applies rather than reading it twice.
Questions
Sometimes, and we will say so when it is right — a content-heavy site with several editors and a plugin ecosystem it genuinely needs is a reasonable fit. We do not use it as a default, because a page assembled from a page builder and eleven plugins carries JavaScript nobody chose and a maintenance surface nobody owns. Where we build in Next.js instead, the trade is a faster site with a smaller attack surface and a smaller pool of people who can edit the code.
We hold Core Web Vitals in the good band on a mid-range Android phone over a throttled connection, not on a desktop over office fibre, and the budget is checked on every change rather than at launch. The specific numbers depend on what the site has to carry — a page with a video is not a page with three paragraphs — so we agree the budget for your pages before building and enforce that.
Yes, and it usually improves the result. What we need from a brand guide is the type scale, the palette with its intended contrast pairings, and the spacing rhythm. If those are not defined we will define them and hand them back as tokens shared between the design files and the code, so the two do not drift apart during the build.
You own the repository, the hosting accounts and the content system from day one, so nothing is hostage. Beyond that it is your choice: a support arrangement where we handle dependency updates, monitoring and small changes, or a clean handover with the documentation to take it in-house. We are equally willing to do the second.
That is the case we build for. Server-rendered HTML means the first screen is text, not a loading state waiting on JavaScript. Images are pre-encoded at real widths so a phone never pulls a desktop file, fonts are subset and self-hosted, and anything below the first screen loads lazily against a reserved box so nothing jumps.
Also in products
Web platform
A signed-in system in the browser: records, roles, state changes and an audit trail behind them.
Mobile product
An installed app for iOS and Android, built to work on a bad connection and to survive a store review.
Describe what the finished thing has to do and who has to use it. We will tell you which parts of a websites build are the expensive ones in your case, and where a smaller first release would get you most of the value.
What happens next
