Website Development
We build websites that load quickly, work on every device, can actually be read by search engines and AI crawlers, and hand over cleanly at the end. That last part sounds obvious and frequently is not. We are based in Oldbury, in the West Midlands.
Server-rendered pages with unique titles, meta descriptions and a single h1 present in the source · Structured data — Organization, LocalBusiness, Service, BreadcrumbList, FAQPage where applicable — validated and matching the page · Performance as a build requirement: modern image formats, responsive sizing, lazy loading below the fold, explicit dimensions, minimal render-blocking resources, sensible caching · Accessibility fundamentals — semantic HTML, keyboard navigation, contrast, alternative text, focus states
On this page
- What kinds of website do we build?
- Why does rendering decide whether Google and AI can read your site?
- What does “server-rendered by default” actually mean?
- How fast should your website be, and what makes it slow?
- Does site speed actually affect rankings, or just conversions?
- What does “built properly” include as standard?
- What do we actually build in?
- Who owns the code, the accounts and the site at the end?
- What happens if you want to move to another developer?
- What drives the cost of website development?
- What moves the price of a build?
What kinds of website do we build?
Seven kinds of work: content-managed sites, headless and framework builds, custom applications, e-commerce, integrations, migrations, and performance rescue on a site somebody else built. Most projects are the first; the rest are what happens when the requirement turns out to be bigger or smaller than a rebuild.
- Content-managed websites. WordPress and other content management systems, built properly — custom themes rather than a bloated page builder, only the plugins that earn their place, and an editing experience your team can actually use. Most business websites belong here, and there is no shame in it: WordPress runs a substantial share of the web because it works.
- Headless and modern framework builds. Where performance or complexity justifies it, a decoupled front end — React or Next.js — with a headless CMS behind it. Faster and more flexible, and more expensive to build and maintain. We will tell you honestly when your project does not need it, which is more often than the industry likes to admit.
- Custom applications. When the site stops being pages and becomes something people log into and use, the job is a web application build rather than a website project, and it is scoped differently.
- E-commerce. Product catalogues, payments, shipping and VAT, stock integration — all of which sit on the online store side of the practice.
- Integrations. Connecting the website to the systems behind it: your CRM, your accounting package, your stock system, your booking platform, your email marketing. This is usually where a website stops being a brochure and starts saving money, and where connecting it to a CRM pays for itself.
- Migrations and replatforming. Moving from one platform to another without losing content, rankings or your mind. Full URL mapping and redirects planned before anything moves.
- Performance work. Taking an existing slow site and making it fast. Often cheaper than a rebuild and frequently what a client actually needs.
Why does rendering decide whether Google and AI can read your site?
Because when someone visits your site, one of two things happens. Either the server sends a finished page — the words, the headings, the structure, all present in the response — or the server sends an almost empty shell and JavaScript builds the page in the visitor's browser afterwards. To a person, these look identical. To a machine, they are completely different. It is the most consequential technical decision in a modern website build and it is usually made without the client being told it exists.
Google can execute JavaScript, but it does so on a delay and a budget, and on larger sites it is applied inconsistently. Many other things that read your site cannot execute JavaScript at all: a large share of AI and answer-engine crawlers, social media preview bots, and various SEO and monitoring tools. To all of those, a client-rendered site is a blank page — which is why this one decision sits underneath most answer engine visibility problems we are asked to solve.
We know exactly how bad this gets, because it happened to us. Our own site served 47 URLs that all returned the same title, the same description, no h1 and fifteen words of body text to any crawler that did not render JavaScript. We found it, we fixed it, and it is now something we check on every build and on every crawl and indexation audit we run.
The point
We found it, we fixed it, and it is now something we check on every build and on every crawl and indexation audit we run.
What does “server-rendered by default” actually mean?
Content exists in the HTML response. Titles, descriptions, headings and structured data are all present before a single line of JavaScript runs. This is not exotic — it is a configuration decision, made correctly, at the start.
How fast should your website be, and what makes it slow?
Google's thresholds are a largest element painted within 2.5 seconds, interactions answered within about 200 milliseconds, and a layout that barely moves. On a build, what breaks them is rarely the design: it is the rendering approach, the weight of the JavaScript, how long the server takes to answer and what is cached. The platform decision underneath it — WordPress or a custom build — sets how much of this you inherit.
| Metric | What it measures | What usually breaks it |
|---|---|---|
| Largest Contentful Paint (LCP) | How long before the biggest element in the viewport is actually on screen. Good is 2.5 seconds or less. | An uncompressed hero image served at full resolution to a phone, a slider loading every slide up front, a render-blocking stylesheet, and webfonts that arrive late and repaint the headline. |
| Interaction to Next Paint (INP) | How quickly the page responds when someone taps, types or opens a menu. Good is around 200 milliseconds. | An oversized JavaScript bundle shipped to every page whether it needs it or not, plus third-party tags — consent banners, chat widgets, heatmaps and the pixels added for paid campaign tracking — all competing for one main thread. |
| Cumulative Layout Shift (CLS) | How much the page jumps after it first paints, usually while someone is trying to tap something. Good is 0.1 or less. | Images and embeds with no dimensions reserved, banners and ads injected above existing content, and fonts swapping in at a different size once they load. |
| Time to First Byte (TTFB) | How long the server takes to begin answering, before the browser has anything to work with at all. | A cheap shared host, an uncached content management system rebuilding every page on every request, a database query nobody profiled, and redirect chains left over from an old migration. |
Does site speed actually affect rankings, or just conversions?
Both, but unevenly. In search, speed behaves as a tie-breaker rather than a primary ranking factor: relevance wins first, and a fast page only decides between pages that are otherwise close. Commercially the argument is stronger, because a slow page loses people before it has said anything.
We are not going to put a percentage on that, because we do not have one for your site and neither does anybody quoting one at you. What we can say is where the time goes in a build. Most slow sites we are handed are slow for two or three findable reasons — everything is rendered in the browser, the JavaScript bundle ships code the page never uses, the host is shared and uncached, the images are full-size originals — and each of those is fixable without a redesign.
The version of this that genuinely affects rankings is usually not the score in a testing tool but the thing underneath it: pages a crawler struggles to render, a server slow enough to limit how much of the site gets crawled at all, redirect chains nobody cleared up. The version that affects money is measured against the enquiry rate rather than against a score, which is what changing one thing at a time on a live page is for. Neither is a substitute for the search work itself, and we would not sell it as one.
What does “built properly” include as standard?
Eight things are in every site we build and none of them is an upsell: server rendering, structured data, performance, accessibility, security, analytics, redirects and documentation. They are the difference between a site that works on the day it launches and one that still works two years later.
- Server-rendered pages with unique titles, meta descriptions and a single h1 present in the source.
- Structured data — Organization, LocalBusiness, Service, BreadcrumbList, FAQPage where applicable — validated and matching what is on the page.
- Performance as a build requirement, not a later optimisation. Modern image formats with responsive sizing, lazy loading below the fold, explicit dimensions to prevent layout shift, minimal render-blocking resources, sensible caching.
- Accessibility fundamentals — semantic HTML, keyboard navigation, contrast, alternative text, focus states — carried through from the design stage rather than added at the end.
- Security — HTTPS, hardened admin access, dependency monitoring, regular patching.
- Analytics and conversion tracking configured and tested, with events for forms, calls, emails and WhatsApp clicks. A site that cannot tell you where enquiries come from is a site you cannot improve.
- Redirect mapping from your old URLs, so a redesign does not cost you the rankings you already have.
- Documentation and training, so you are not dependent on us for a text change.
What do we actually build in?
Only what we genuinely work in: React, Next.js and TypeScript on the front end, WordPress with custom themes or a headless CMS for content, Node.js, Laravel and Python behind them, PostgreSQL, MySQL and MongoDB for data, and REST or GraphQL where the site has to talk to something else.
- Front end — React, Next.js, TypeScript, modern HTML and CSS
- CMS — WordPress with custom themes, and headless CMS options where the case justifies it
- Back end — Node.js, PHP (Laravel), Python
- Databases — PostgreSQL, MySQL, MongoDB
- Infrastructure — UK and EU hosting, containerised deployment, automated backups, monitoring
- Integration — REST and GraphQL APIs, webhooks
Who owns the code, the accounts and the site at the end?
You do, on final payment — the codebase, the designs, the content and every account, with no buyout fee and no proprietary framework that only we can maintain. This is the section worth reading twice, because it is where clients most often discover a problem years later.
- You own the code. On final payment, the codebase, the designs and the content are yours. We hand over the repository.
- You own the accounts. Domain, hosting, analytics, and every third-party service is registered to you, in your name, on your email. Not ours. If we register something on your behalf during the build, it is transferred at handover.
- No proprietary lock-in. We build on standard, widely-used technologies. Any competent developer can pick up the work. We do not use an in-house framework that only we can maintain.
- No buyout fee. Some agencies build your site on a subscription and charge a multiple of the monthly fee — commonly twelve months' worth — if you want to own it. We do not do this. It is a legitimate business model and it is one you should know you are signing up to.
- If you leave, we help hand over and answer your new developer's questions during the transition.
What happens if you want to move to another developer?
You take the lot, and we answer your new developer's questions while they settle in. A handover is a specific list rather than a gesture: the repository and its history, the content, the credentials, the build instructions and the accounts. Any one of those missing is what makes leaving expensive.
- The repository, with its history. Not a zip of the current files — the actual commit history, so whoever picks it up can see why something is the way it is instead of guessing.
- The content management system, and an export of the content. Admin access transferred, plus the content itself in a format that can be read outside the platform, because the words and the images are yours regardless of what they currently sit in.
- Environment variables and third-party credentials. API keys, payment and email-sending credentials, webhook endpoints, and whatever the site needs to talk to your CRM or back-office system. Listed in one place rather than scattered through a codebase.
- Deployment and build instructions. How to run it locally, how to build it, where it deploys and what the pipeline does. This is the part most often missing, and it is the difference between a new developer starting straight away and reverse-engineering the setup first.
- The domain and DNS, in your name. Registered to you, on your email, with access you can use without asking permission. The same goes for the DNS records, which are what actually control where your website and your email point.
- Hosting, analytics and search tooling, also in your name. The hosting account, the analytics property, Search Console, the tag manager, any monitoring. If we set one up during the build, it is transferred rather than kept.
- The design files and the written documentation from handover, so nobody is re-deriving decisions that were already made and paid for.
- And a conversation. We will talk to whoever takes it on and answer their questions during the transition. If you are weighing up where to move, a freelancer, an agency and an in-house hire fail in different ways and it is worth knowing which you can live with — and if you have just inherited a site somebody else built, send us what you were given and we will tell you what is missing.
What drives the cost of website development?
What a build costs is set by the type of site rather than by the technology. The bands below are how to place yourself before a conversation; page count, content, integrations and how bespoke the design is are what move you within one. They are the same bands used for the design stage, because for most projects design and build are one piece of work.
| Type | What it is |
|---|---|
| Starter | Up to about 8 pages, custom design, content management, forms, analytics, basic structured data. |
| Business | 10–25 pages, full CMS, service and location page architecture, blog, complete structured data, conversion tracking. The most common project. |
| E-commerce | Catalogue, payments, shipping and VAT, stock and accounting integration. |
| Custom build | Applications, portals, complex integrations, headless architecture, multi-site. Scoped individually. |
| Performance or rescue work | Taking an existing site and fixing speed, rendering, structure or security without a rebuild. |
What moves the price of a build?
Five things, in roughly the order they matter: page count; whether you supply copy and photography or we produce them; the number of integrations and whether your systems have usable APIs; how bespoke the design is; and how settled the requirements are before we start. Ongoing care is quoted separately.
- Page count.
- Whether you supply copy and photography, or we produce them.
- The number of integrations, and whether your systems have usable APIs.
- Whether the design is bespoke or adapts a proven pattern.
- How settled the requirements are before we start.
- After launch, updates, security, backups and monitoring sit on a monthly website care plan rather than in the build price.
How We Work
Structure and specification
What pages exist, what each does, what it connects to, and how content is managed. Agreed before development starts.
Design
Wireframes, then visual design, then build-ready specifications.
Build
In two-week sprints, with a staging site you can look at throughout. No long silence followed by a reveal.
Content
Loaded, formatted and optimised. If you are supplying it, we give you a per-page brief so you know what each page needs to cover.
Explore Related Services
Frequently Asked Questions
How much does website development cost in the UK?
“A website” describes things thirty times apart in cost, so a single figure would tell you nothing. What separates them is page count, whether content and photography are included, how many other systems the site talks to and whether those have usable APIs, and how settled the requirements are before we start. We scope it before quoting.
Will we own the source code?
Yes, on final payment, along with the designs, the content and every account — domain, hosting, analytics. We hand over the repository with its history, not a zip file. There is no buyout fee. Ask this of every developer you speak to; the answers vary more than you would expect.
Do you build on WordPress or custom?
Both, and the choice should follow the requirement rather than our preference. WordPress for most content-led business sites — it is mature and your team can edit it. A modern framework where performance or application complexity justifies it. If WordPress is right for you we will say so, even though a custom build is a larger invoice.
Can you take over a site another agency built?
Usually. We start with a review: what it is built on, the state of the code, what is out of date, what is broken, and whether it is economic to maintain. Sometimes the honest answer is that a rebuild costs less than continuing to patch it, and we will show you the reasoning rather than just asserting it.
How do you make sure the site is fast?
Performance is a build requirement rather than a later fix. Server-rendered pages, modern image formats with responsive sizing, lazy loading below the fold, explicit image dimensions, minimal render-blocking resources, sensible caching, and a critical eye on third-party scripts — analytics, chat widgets and tracking pixels are the most common cause of a slow site that was fast at launch.
What happens after launch — do you maintain it?
If you want us to. Monthly care plans cover updates, security patching, backups, uptime monitoring and an agreed allocation of content changes. It is optional and it is not a condition of the build — if you have hosting and support arrangements you are happy with, we will work alongside them.
Can you integrate the site with our CRM or other systems?
Yes, and it is often where the real value is. Anything with an API, and frequently things without one. We check what your systems can actually do during scoping rather than assuming, because integration is where optimistic estimates most often go wrong.
How long does a website take?
Three things decide it: the size and complexity of the site, how many other systems it has to connect to, and how quickly the content arrives. Content is the most common cause of delay on every project we run. If timing matters, have the words and images ready, or ask us to produce them.
Let's Build Something That Matters.
Tell us what you're trying to achieve and we'll help you find the right solution.