What to Expect When You Hire a Web Developer: A Practical Guide for UK Business Owners
The Process Is More Predictable Than You Think
One of the most common things I hear from new clients is that they've had a bad experience with a web developer before — not because the work was technically poor, but because the process felt opaque. They didn't know what was happening, timelines slipped without explanation, and the final result wasn't quite what they had in mind. Most of that comes down to process, not skill. Here's what a well-run web development project looks like, so you know what to expect and what to ask for.
Discovery Comes First
Before any code is written, a good developer will spend time understanding your business, your customers, and what the website actually needs to do. This might be a call, a questionnaire, or both. It's worth being thorough here — the more clearly you can describe who your customers are and what you want them to do on the site, the better the end result will be. If a developer skips this stage and goes straight to design, that's a warning sign.
What You'll Be Asked to Provide
You should expect to supply: your branding assets (logo, colours, fonts — or a brief if you need these created); written copy for the key pages, or an agreement that copywriting is included in scope; any existing imagery you want to use; examples of sites you like and, crucially, what you like about them. The last point matters more than most clients realise. "I like that site" is less useful than "I like how that site makes the main service obvious in the first screen."
Realistic Timelines
A straightforward brochure site for a small business — five to eight pages, clear content, no complex functionality — typically takes three to six weeks from start to launch, assuming content is provided promptly. Add e-commerce, custom web applications, or content-heavy sites and you're looking at longer. The most common source of delay in my experience isn't the development work — it's waiting for content and feedback from the client side. Building in time for review rounds at the start avoids pressure at the end.
Reviews and Feedback
A structured project will include defined review points — typically after the initial design, after the build, and before launch. At each stage, you should receive something to review and a clear way to submit feedback. Vague feedback makes everyone's life harder; specific feedback is easy to act on. Most developers will include two rounds of revisions per stage; anything beyond that is usually chargeable, which should be agreed upfront.
After Launch
The end of a build isn't the end of the relationship. You'll want to know who handles updates and security patches going forward, what happens if something breaks, and whether ongoing support is available and at what cost. A developer who disappears after launch is a common frustration — it's worth asking about this explicitly before you start. If any of this sounds like the conversation you need to have before your next project, I'm happy to talk through your specific situation with no obligation.
