What are web development services? A practical guide for buyers

Web development services are the work of planning, designing, building, launching and looking after websites and web applications. A full service covers discovery, user experience and visual design, front-end development (what runs in the browser), back-end development (servers, databases and APIs), content management, integrations, hosting, testing, security and ongoing support. You can buy all of it from one partner or just the parts you are missing.

That definition hides a wide range. A five-page brochure site and a customer portal handling payments are both 'web development', but they differ in effort, risk and skills by an order of magnitude. This guide breaks the field into its parts, explains how a project runs, and covers the things buyers most often discover too late: performance, accessibility law, security, search visibility and who owns what at the end.

What web development services include

Agencies package their services differently, but almost every serious web project draws on the following disciplines. A small project may need a few of them for a few days; a large web application needs all of them throughout.

• Discovery and strategy: agreeing goals, audiences, scope, success measures and constraints before anything is designed. The cheapest place to change your mind.
• UX and UI design: information architecture, user journeys, wireframes, prototypes and the visual design system. See our product design service.
• Front-end development: turning designs into fast, accessible, responsive pages and interfaces that run in the browser.
• Back-end development: the server side, including databases, business logic, APIs, user accounts, permissions and background jobs.
• Content management: setting up a CMS so your team can publish and edit without a developer, plus content modelling and migration from an old site.
• E-commerce: catalogues, carts, checkout, payments, tax, shipping and order management, on a platform or built custom.
• Integrations: connecting the site to your CRM, marketing tools, payment providers, ERP, booking systems or data warehouse.
• Hosting, DevOps and deployment: infrastructure, environments, automated deployments, backups, monitoring and a content delivery network.
• Quality assurance: functional, cross-browser, device, accessibility and performance testing before every release.
• Technical SEO and analytics: making pages crawlable and measurable, with consent-aware analytics.
• Security: secure coding, dependency updates, security headers, access control and testing.
• Maintenance and support: updates, fixes, monitoring and small improvements after launch.

Websites, web apps and everything in between

The first thing a good partner will establish is what kind of web product you need, because it decides the team, the technology and the effort. These are the five common shapes.

Front-end, back-end and full-stack: who does what

Front-end developers build what the user sees and interacts with in the browser, using HTML, CSS and JavaScript or TypeScript, usually with a framework such as React, Vue or Svelte. Back-end developers build what happens on the server: storing and retrieving data, enforcing business rules, checking who is allowed to do what, and talking to other systems. Full-stack developers work across both.

For a marketing site, most of the effort is front-end and design. For a web application, the back end usually dominates. Modern frameworks blur the line by rendering pages on the server, which is one reason small, senior teams that understand both sides often move fastest. Our guide to frontend vs backend development explains the split in detail.

How a web development project runs

Methods vary, but well-run projects follow the same arc. Durations below are typical for a mid-sized project and vary widely with scope.

1. Discovery (often one to three weeks). Goals, users, content inventory, integrations, technical constraints and a prioritised scope. Output: a plan and an estimate you can trust more than a guess.
2. Design (two to six weeks, overlapping with build). Site map, key user journeys, wireframes, then a visual design system and the main page templates, tested with real content rather than placeholder text.
3. Build in short iterations. Front-end and back-end work in parallel against agreed interfaces, with a working version deployed to a staging environment you can click through every week or two.
4. Content and migration. Loading real content, redirecting old URLs and checking nothing important is lost. Frequently underestimated.
5. Testing. Functional, cross-browser and device testing, accessibility checks, performance measurement and a security review.
6. Launch. A rehearsed go-live with a rollback plan, DNS changes, monitoring switched on and search engines told about the new structure.
7. Support and evolution. Fixes, updates and improvements based on real usage data. A website is never really finished.

Choosing the technology: CMS, frameworks and hosting

There is no best stack, only a best fit for your content, team and ambitions. The main approaches, with honest trade-offs:

A related decision is how pages are rendered: on the server for each request, generated in advance as static files, or assembled in the browser by JavaScript. Google's guide to rendering on the web recommends favouring server-side or static rendering over shipping a large JavaScript application to every visitor, and mixing approaches page by page. For most marketing and content sites, that means pre-rendered or server-rendered pages with a little JavaScript where it adds value.

Hosting has shifted too. Many sites now run on managed platforms or serverless infrastructure with a global content delivery network in front, which removes much of the work of running servers. Larger web applications still need a deliberate cloud architecture. Either way, insist on automated deployments, separate staging and production environments, and backups you have actually tested restoring.

Performance is a feature: Core Web Vitals

Speed affects conversions, user satisfaction and how search engines judge your pages. Google measures real-user experience with three Core Web Vitals: Largest Contentful Paint (loading) should happen within 2.5 seconds, Interaction to Next Paint (responsiveness) should be 200 milliseconds or less, and Cumulative Layout Shift (visual stability) should be 0.1 or less. The thresholds are assessed at the 75th percentile of real visits, so a fast experience on your office broadband proves little.

Most of the web still misses the mark. The 2025 Web Almanac from HTTP Archive found that only 48% of mobile sites achieved good scores on all three Core Web Vitals, against 56% on desktop. Mobile is where most visitors are and where most sites fall short.

• Set performance budgets for page weight and JavaScript at the start, and check them on every release.
• Serve modern image formats at the right size, and give images and embeds fixed dimensions so the layout does not jump.
• Load fonts efficiently, self-hosted and subset where possible.
• Lazy-load video, animation and third-party widgets, and question every tracking script.
• Measure with field data from real users, not only lab tools.

Accessibility is now a legal requirement in many markets

An accessible website works for people who use screen readers, keyboards, magnification or voice control, and for anyone with a slow connection, an old phone or a bright sunny day. The international benchmark is the W3C's Web Content Accessibility Guidelines (WCAG) 2.2, and most laws and procurement rules point to level AA.

The gap between the standard and reality is wide. WebAIM's 2026 analysis of the top million home pages detected WCAG failures on 95.9% of them, with low-contrast text, missing image descriptions and unlabelled form fields the most common problems. Almost all of these are cheap to avoid when built in and expensive to retrofit.

The law has caught up. The European Accessibility Act has applied since 28 June 2025 to a range of consumer services, including e-commerce and banking, offered to people in the EU, wherever the business is based. Microenterprises providing services are exempt, but most growing companies are not. Public-sector bodies in the EU and UK have had accessibility duties for longer. Ask any web partner how they test for accessibility, not just whether they do.

Performance, accessibility and security are not features you add at the end. They are properties of how the site is built, and a site built without them has to be partly rebuilt to get them.

Security: what a competent team does by default

Even a simple website collects form data, runs third-party scripts and depends on dozens of open-source packages. A web application holds customer data and money. The OWASP Top 10:2025 lists the most critical web application risks, led by broken access control, security misconfiguration and software supply chain failures. None of them is exotic, and all of them are prevented by habits rather than heroics.

• Access control checked on the server for every request, never only hidden in the interface.
• Validated and parameterised input everywhere data enters the system.
• HTTPS everywhere, with sensible security headers and a content security policy.
• Dependencies scanned and updated on a schedule, with a lockfile and a minimal set of packages.
• Secrets kept out of the code repository, with least-privilege access to databases and cloud accounts.
• Multi-factor authentication on every admin, hosting and domain account.
• Logging and alerts for suspicious activity, and backups that are tested.
• A security review or penetration test before launching anything that handles personal or payment data.

Search and content foundations

Developers do not write your content, but they decide whether search engines and AI assistants can read it. Good technical foundations include semantic HTML with one clear heading structure per page, unique titles and descriptions, an XML sitemap, clean and stable URLs, structured data where it helps, correct language tags for multilingual sites, and pages that render meaningful content without waiting for heavy JavaScript.

One of the most damaging mistakes in website projects is a redesign that changes URLs without redirects. Years of search visibility can disappear overnight. Before launch, map every important old URL to its new home with permanent redirects, as Google's guidance on moving a site with URL changes describes, and monitor search console reports for weeks afterwards.

Analytics, consent and privacy

A website you cannot measure is a website you cannot improve, but measurement now comes with legal duties. In the UK, the EU and a growing number of other places, non-essential cookies and similar trackers generally need the visitor's informed consent before they run, and personal data collected through forms needs a lawful basis, a clear privacy notice and a sensible retention period. Getting this wrong is a regulatory risk and, just as importantly, a trust problem.

• Decide what you actually need to measure, such as leads, sign-ups, purchases and key journeys, before adding tools. Fewer scripts mean faster pages and simpler consent.
• Use a consent banner that blocks non-essential trackers until the visitor agrees, and makes refusing as easy as accepting.
• Prefer privacy-friendly or server-side analytics where they meet your needs.
• Send form submissions straight to the system that needs them, such as your CRM, over secure connections, and do not leave copies in email inboxes or logs.
• Document which third parties receive data from the site, and have data-processing agreements in place with each.

Ownership: domains, code, accounts and content

This is the topic agency brochures leave out, and it causes the most painful disputes. When the project ends, or the relationship does, you should be able to carry on without asking anyone's permission. Before you sign, confirm that you will own or control:

• The domain name, registered in your company's name in a registrar account you control.
• DNS, hosting and cloud accounts, with your billing details and your admin users.
• The source code, in a repository your organisation owns, with the intellectual property assigned to you in the contract.
• Design files and the design system, in your own workspace.
• CMS, analytics, tag manager and search console accounts, with you as owner.
• Licences for fonts, images, plugins and themes, bought in your name where possible.
• Documentation good enough for another team to run and change the site.

What drives the effort, and how estimates are built

Web projects vary from days to many months. The biggest drivers are the number of distinct page templates and user journeys, the complexity of the back end and data model, the number and quality of integrations, content volume and migration, the number of languages, accessibility and compliance requirements, and how much custom design and animation you want. Unknowns drive effort too, which is why a short discovery phase usually saves money.

As illustrations of shape rather than quotes: a focused marketing site with a headless CMS, around ten templates and two integrations might take a senior engineer and a designer six to ten weeks. A customer portal with accounts, permissions, payments and integrations with a CRM and billing system might need two or three engineers plus a designer for three to six months for a first release. To build an estimate for your own case, use our software cost calculator, and read how much custom software development costs for the drivers in more depth.

How to evaluate a web development partner

Portfolios show what a team can make look good. These questions show how they work:

For a fuller checklist, including red flags in proposals and contracts, see how to choose a software development company.

How Authect approaches web development

Authect is a founder-led studio: you talk to the founders who build your project, never a salesperson. Every web project is led by a senior engineer who works across front end and back end, in a small team that keeps decisions close to the code. We use AI to accelerate delivery, and an engineer reviews every line before it ships. Performance, accessibility and security are part of the definition of done rather than extras, and you own the code, infrastructure, designs and accounts from day one, with no lock-in.

We work as fixed-price projects for well-defined scopes, monthly sprints for products that keep evolving, and support and evolution once you are live. If you are planning a new site or web application, or rescuing one that is slow, inaccessible or hard to change, get in touch.