What Business Owners Should Know Before Hiring a Web Developer

I've been on both sides of this conversation. As a freelance developer, I've been hired by businesses who had no idea what they were getting into. I've also cleaned up messes left by developers who oversold and underdelivered.

The web development industry has a trust problem. There's no licensing. No standardized qualifications. Anyone can call themselves a developer. Some are excellent. Some are terrible. Most are somewhere in between, and figuring out which is which isn't obvious if you're not technical.

This is what I'd tell a friend who was about to hire someone.

Start By Understanding What You Actually Need

Before you talk to anyone, get clear on what you're trying to accomplish. Not what technology you want, but what business outcome you're after.

"I need a new website" is too vague. Why do you need a new website? Is the current one slow? Not converting? Hard to update? Looks dated? All of those point to different solutions.

"I need my site to generate more leads" is better. Now we can talk about what's preventing that and what would help.

"I need my site to load faster and rank better on Google" is specific enough to evaluate. A developer can audit your site, identify the problems, and give you a realistic estimate.

The more specific you can be about the problem, the easier it is to evaluate whether someone can actually solve it.

Questions That Reveal Competence

Anyone can talk a good game. These questions help you figure out if they can actually deliver.

"Can you show me three sites you've built recently?"

Not screenshots. Working sites you can actually visit and click around. If someone has no portfolio or won't show recent work, that's a red flag. If the sites they show are slow, buggy, or look like they were built in 2015, that tells you something too.

Visit the portfolio sites on your phone. Load them on mobile data if you can. See how they actually perform in real conditions.

"What would your approach be for my project?"

A good developer will ask questions before answering this. They'll want to understand your business, your users, your constraints. If someone jumps straight to "we'll build it in React" or "we'll use WordPress" without understanding the problem, they're fitting your project to their hammer.

The best answer often starts with "it depends" or "I'd need to understand more about..."

"What happens if something goes wrong after launch?"

Every project has bugs. Things break. Requirements get misunderstood. The question is how they handle it.

Look for developers who include a warranty period - typically 30-90 days of bug fixes after launch. Ask about their availability for ongoing support. If they disappear after final payment, you're on your own when something breaks.

"How do you handle scope changes?"

Scope always changes. You'll discover something midway through that needs to be different. How does that get handled?

Some developers charge for every small change. Some include reasonable revisions. Neither is wrong, but you should know which you're getting. The red flag is vagueness - "we'll figure it out" usually means arguments about money later.

"What's your timeline, and what could affect it?"

Anyone can give you an optimistic timeline. Ask what could slow things down. A developer who's honest about dependencies, review cycles, and potential blockers is more likely to deliver than one who promises everything will be done in two weeks.

Red Flags I've Seen

These aren't always dealbreakers, but they should make you ask more questions.

No contract or very vague contract. Professionals use contracts. They protect both sides. If someone is resistant to putting things in writing, wonder why.

Everything happens through one person with no backup. What happens if they get sick? Go on vacation? Decide to quit freelancing? At minimum, you should have access to your own code and hosting.

They promise everything. Design, development, SEO, content, marketing, branding - all at expert level from one person? Unlikely. Specialists are usually better than generalists for any specific thing.

Much cheaper than everyone else. If three developers quote $15,000 and one quotes $3,000, the cheap one is either cutting corners, underestimating the work, or desperate enough to take a loss. None of those are good for you.

They're vague about technology choices. "We'll use modern technologies" means nothing. A developer should be able to explain why they're recommending what they're recommending, in terms you can understand.

Pushy about decisions you don't understand. If someone is pressuring you to sign immediately or commit to technology choices you can't evaluate, slow down. Good developers are patient with questions.

How Pricing Usually Works

There's no standard pricing. Rates vary by experience, location, specialization, and how much the developer values their time. But here are rough patterns I've seen in the UK market:

Junior freelancers and overseas agencies: £30-60/hour, or fixed projects starting around £1,500 for simple sites. Quality varies wildly. Some are excellent value. Some will produce unusable work.

Mid-level freelancers: £60-100/hour, or fixed projects from £5,000-15,000 for typical business sites. More reliable, but still varies.

Senior freelancers and boutique agencies: £100-150+/hour, or fixed projects from £15,000-50,000+. You're paying for experience, reliability, and better problem-solving. Whether that's worth it depends on your project.

Fixed-price quotes tend to be safer for straightforward projects. Hourly works better for ongoing work or projects where the scope isn't clear. Retainers work well for ongoing relationships where you need regular availability.

Get the pricing structure in writing before work begins. "Around £10,000" isn't a quote. "£10,000 for the deliverables listed in this document" is.

What You Should Get

At minimum, when a project wraps up, you should have:

Access to everything. Your domain registration, hosting account, code repository, any third-party services (analytics, email, etc.). If you can't log into these yourself, you don't own them.

Documentation. How to update content. How to add blog posts. Where the hosting is and how to access it. What the login credentials are. This doesn't have to be extensive, but you should be able to do basic tasks without the developer.

Clean handoff. If you hire someone else later, they should be able to pick up where things left off. That means organized code, sensible structure, standard practices. Ask if the previous developer's code would make sense to another developer.

Questions to Ask Yourself

Before you hire anyone, be honest about:

What's your real budget? If you have £3,000 to spend, you can get a decent WordPress site but not a custom web application. Knowing your constraints upfront prevents wasted conversations.

How involved do you want to be? Some business owners want to see every design iteration. Others want to hand over requirements and see the finished product. Neither is wrong, but you and your developer need to be aligned.

What does success look like? More leads? Faster page loads? Easier content updates? A site you're proud to show clients? Define this before the project starts and measure it after.

What's your actual timeline? If you need something in two weeks, that limits your options. If you've got three months, you can be more selective about who you work with.

Finding Good Developers

The best developers are usually found through referrals. Ask other business owners who built their site. Check if you know anyone who works in tech who could recommend someone.

If you're searching cold, LinkedIn and Dribbble for designers, GitHub for developers who share their work, and good old Google for local agencies. Look at their work before reaching out.

When you reach out, include: what your business does, what you need, rough timeline, rough budget. Developers get a lot of vague "I need a website" inquiries. Specific ones get better responses.

One Last Thing

The developers who do the best work tend to push back sometimes. They'll tell you when your idea won't work, when your timeline is unrealistic, when you're about to make a mistake. That's not being difficult - that's doing their job.

The ones who say yes to everything, who promise the moon, who never raise concerns - those are the ones who deliver problems later.

You're hiring expertise. Let them use it.