A national web development brief in the UK is usually written for the wrong engagement
Buyers searching at country level have already decided that the supplier does not need to be down the road, which is sensible, since the work happens in a repository and the meetings happen on a call. What most have not decided is the shape of the engagement, and that omission causes more disappointment than any technical choice.
Web development is sold in two honest shapes. One is a defined project with a fixed scope, a fixed price and an end date. The other is a continuing arrangement where a team works through a prioritised list for as long as you fund it. Everything else is one of those two wearing the other's clothes, and the mismatch usually shows up around the third month.
Fixed scope buys certainty and charges for it
A fixed price only exists because the supplier has priced the risk of being wrong. That is a fair trade if your requirements are genuinely settled, if someone on your side can approve decisions quickly, and if you are content to put anything new into a second phase.
It goes badly when the scope was never really fixed. Every change becomes a negotiation, the relationship turns adversarial, and the supplier starts defending the letter of the specification because that is what they are being paid against. If you suspect your requirements will move, do not buy certainty you cannot keep still enough to use.
Continuous arrangements need someone on your side to steer
A standing team is flexible, and flexibility has a prerequisite: an owner internally who can decide what matters most this fortnight and say no to everything else. Without that person the backlog becomes a queue of requests from whoever asked most recently, and the spend continues while the site does not visibly improve.
Before committing to a retainer, name the person, give them the authority, and agree how progress is reported. A short written note each month covering what shipped, what slipped and what the supplier needs from you is enough. A retainer that produces no visible output is the easiest thing in web development to keep paying for.
Three things decide the price whichever model you pick
The first is the content model: whether pages are built from structured, reusable types that your team can publish, or assembled by hand in a builder each time. The second is integration: every system the site exchanges data with, who owns each interface, and what the page shows when one is unavailable. The third is hosting: where the site runs, whose account pays for it, and whether the environment is reproducible somewhere else.
Settle all three before requesting quotes. A web development proposal written without them is a guess dressed as a number, and the guess is always defensive.
Consent and tracking are build behaviour, not a banner
Rules here treat the storing of information on a visitor's device as something requiring consent in most cases, and a banner that appears while tracking has already fired does not deliver that. The requirement is that scripts do not load until consent exists, which is an implementation detail that reaches analytics, embedded video, chat widgets, maps and advertising tags.
Ask candidates how consent state is stored, how it is honoured by anything loaded later, and what happens on a page where a marketing team adds a tag without telling anyone. Ask who is accountable for keeping the list of third parties accurate, because that list drifts constantly and nobody owns it by default.
Accessibility applies whether or not you sell to government
Public sector suppliers meet an explicit standard, but the underlying duty not to discriminate against disabled users applies to organisations offering services to the public generally. The practical work is the same either way, and it belongs to web development rather than to a later review: semantic markup, keyboard operation, visible focus, labelled fields, contrast, heading order, captions.
Ask whether the team tests with a screen reader and against WCAG criteria or whether accessibility means an automated report the week before launch. Ask to see a complex form they have made accessible rather than a homepage. Doing this during template work costs a fraction of doing it as remediation.
Environments, escrow and what happens if the supplier stops
Before signing, establish that the repository is yours from the first commit, that the deployment process is written down rather than held in one person's memory, and that a staging environment exists which resembles production. These sound like technical housekeeping and they are actually the difference between switching suppliers in a fortnight and rebuilding.
For business critical sites, ask about source code escrow and about how many people at the supplier could realistically pick up your codebase. Ask what is proprietary to them, what licence you hold to it, and what that licence says if you leave. Custom tooling can be excellent work and it can also be a lock, and you should know which one you are buying.
Comparing web development companies across the UK
Send the same written brief to a small number of candidates, stating which engagement model you want and why, and ask each to price discovery, build, integration, content migration, accessibility testing, training and support as separate lines. Ask for the proposed team by name and role, and ask how much of each week they are committed to you.
Then ask each for a reference from a client who ended the relationship, and call that client. How a firm behaves at the exit says more than how it behaves at the pitch. You can review verified web development companies in the UK, browse the wider directory of build partners, and gather comparable proposals through our offer request form. Where the work also involves interface decisions, a mobile client or search performance, see web design agencies, mobile app companies and SEO agencies working with the same buyers.