What is website development?
Website development is the work of turning an agreed design into a live, functioning site: the markup, styling, interactivity, content structure and deployment that make pages load quickly, behave predictably and stay maintainable.
It is distinct from web design, which decides how a site looks and reads, and from SEO, which decides what it ranks for. On a healthy project the three run together rather than in sequence, because the decisions that most affect speed and ranking — page structure, heading hierarchy, image handling, what renders on the server — are made during the build, not bolted on afterwards.
What does a website project actually include?
A complete build has four phases, and skipping any one of them is what turns a two-month project into a five-month one. Discovery settles what the site is for and which pages have to exist. Design decides how those pages look and read. Build turns the design into responsive, accessible code. Deployment puts it live and proves it works.
The phase most often cut for budget reasons is discovery — and it is the one that pays for itself. Every week spent agreeing the sitemap and the primary conversion path saves roughly a week of rework later, because changing a page structure after design is expensive and changing it after build is worse.
The four phases, in order
- Discovery — goals, audience, sitemap, conversion path, content inventory agreed before design starts
- Design — bespoke layouts for every template, reviewed in the browser rather than as static images
- Build — responsive implementation, accessibility pass, performance budget, technical SEO foundations
- Deployment — domain and SSL, analytics, monitoring, redirect map, then a post-launch review
How much should a business website cost?
For a professionally built marketing site of five to fifteen pages, most businesses should expect a five-figure sum in the low-to-mid range. Below that you are usually buying a themed template with your logo dropped in; well above it you are paying for custom functionality, integrations or a content-heavy information architecture.
The three things that actually drive the number are page count and template variety, how much content the client supplies versus how much has to be written, and whether anything needs to connect to an existing system such as a CRM, booking engine or product database. Ask any provider to separate those three in their quote — a single blended figure hides which one is inflating it.
Why does site speed affect enquiries, not just rankings?
Speed is a conversion variable before it is a ranking variable. A page that takes three seconds to become usable loses a meaningful share of its visitors before they read a single line, and that loss happens on every page, in every channel, including the paid traffic you are paying per click for.
In practice the fix is rarely one thing. The usual offenders are uncompressed hero images, third-party scripts loaded on every page whether needed or not, layout that shifts as fonts and adverts arrive, and a stack that ships a large JavaScript bundle to render text that never changes. Setting a performance budget before the build — a target for Largest Contentful Paint, Interaction to Next Paint and Cumulative Layout Shift — is what keeps those decisions honest, because it gives the team something concrete to fail against.
Should you redesign, rebuild or reskin your existing site?
These are three different jobs with three different price tags, and quoting the wrong one is the most common way a web project goes over budget. Match the scope to the actual constraint before you ask anyone for a number.
A reskin keeps the structure and changes the surface. A redesign rebuilds the pages while keeping your content and your domain's accumulated authority. A rebuild replaces the platform itself. If your site is slow, the constraint is almost always the platform or the asset handling — and no amount of new visual design will fix it.
Reskin, redesign or rebuild?
Pick the row that matches your actual constraint, not the one that matches your budget.
| Approach | Choose it when | Typical timeline | What you keep |
|---|---|---|---|
| ApproachReskin | Choose it whenBrand or copy changed, but the structure still converts | Typical timeline2–3 weeks | What you keepLayout, codebase, all accumulated SEO equity |
| ApproachRedesign | Choose it whenThe structure no longer matches how people actually buy | Typical timeline4–8 weeks | What you keepContent and domain authority; pages are rebuilt |
| ApproachRebuild | Choose it whenPlatform, speed or the CMS is the real constraint | Typical timeline6–14 weeks | What you keepContent, domain authority and your design language |
How do you choose a platform you will not regret?
Choose the platform that matches who edits the site and how often, not the one with the loudest community. A brochure site that changes twice a year needs a different answer from a catalogue with weekly price updates and a blog.
The two failure modes are symmetrical. Teams pick a heavyweight CMS for a site that will never need it and then pay for the complexity in hosting, security patching and developer time. Or they pick a static generator because it is fast, then discover nobody in the business can publish a blog post without a developer — so the site quietly stops being updated, which costs far more in search visibility than the speed ever gained.
A reasonable default for most marketing sites: a modern framework for the front end, a hosted headless CMS for the content the team actually edits, and a deployment target that gives you preview builds for every change. That combination keeps the site fast without putting the marketing team behind a developer.
What happens after launch?
Launch is the midpoint of a website project, not the end. The first ninety days produce the data that tells you which pages people actually land on, where they abandon, and which of your assumptions about the navigation were wrong.
A sensible post-launch plan covers three things: monitoring that tells you when something breaks before a customer does, an analytics setup that tracks enquiries rather than page views, and a short list of improvements to make once you have real behaviour to look at. We include a post-launch review in every build for exactly this reason, and most clients then move to a light monthly arrangement for iterations rather than starting a new project.