How to choose a web development company

We're an agency writing about how to choose an agency, so read this with appropriate suspicion. What follows is genuinely the framework we'd apply if we were on your side of the table — including several tests we've watched other teams fail, and one or two we've had to learn from failing ourselves.

Start by deciding what you're actually buying

There are three distinct things sold under the label 'web development company', and picking the wrong category is a more expensive mistake than picking the wrong company within a category.

• A body shop sells developer hours. You supply the product thinking, technical direction, and QA. Cheapest per hour, most expensive in your time — and it only works if someone on your side is genuinely technical.
• A delivery agency sells a finished outcome against a defined scope. You supply the goals; they supply the process, judgement, and accountability. This is what most non-technical founders and SMEs actually need.
• A product partner sells ongoing ownership of a product's technical direction. Most valuable if you're building software as your core business, and overkill if you need one platform built once.

If a company can't tell you clearly which of these it is, it's usually the first one describing itself as the third.

Check the four things that actually correlate with outcomes

1. Who writes the code, specifically

Ask for the names and seniority of the people who will work on your project, and what else they're committed to during your timeline. The pitch team and the delivery team being different people is the single most reliable predictor of a disappointing engagement. It's a fair question and a good team will answer it directly.

2. Live work you can inspect

Screenshots prove nothing. Ask for live URLs, then check them yourself: run a Lighthouse audit, open them on your phone, tab through with the keyboard, view the page source. Five minutes of this tells you more about a team's standards than an hour-long pitch.

3. What happens when things go wrong

Every agency has had a project go badly. Ask directly: tell me about one that went wrong and what you did. A team that claims a perfect record is either new or not being straight with you. What you're listening for is whether they took responsibility or blamed the client.

4. Code ownership and exit terms

Get this in writing before you sign: you own the code, the repositories are in your account, the infrastructure is in your name, and there is no proprietary framework you'd have to licence to keep operating. Then ask what handover looks like if you part ways in month three. The answer reveals whether the relationship is built on value or on lock-in.

Questions that separate strong teams from good salespeople

1. 01What would you remove from our scope if you were spending your own money? (Strong teams have opinions and will argue with your brief.)
2. 02What's the riskiest assumption in this project? (If the answer is 'nothing really', they haven't thought about it.)
3. 03How will we see progress between kickoff and launch? (Weekly demos and preview environments; anything less is a black box.)
4. 04What will you need from us, and what happens to the timeline if we're slow? (Honest teams name your obligations upfront.)
5. 05How do you decide when something is done? (Listen for testing, review, and acceptance criteria — not 'it works on my machine'.)
6. 06What does month one after launch look like?

The best signal in any pitch is an agency telling you not to build something. It means their incentive is your outcome, not your invoice.

Warning signs worth walking away from

• A fixed quote produced without any discovery. They're either guessing or planning to make it up in change requests.
• A quote dramatically below every other bid. It's a different, smaller project with your project's name on it.
• Vagueness about who owns the code, or a proprietary CMS or framework you'd be locked into.
• No written scope, or a scope so vague that anything could be argued as out of it.
• Pressure tactics — expiring discounts, a slot that disappears on Friday. Serious engineering firms don't sell like that.
• An inability to explain a technical trade-off in language you understand. If they can't now, they won't in month four either.
• Reluctance to let you speak to a client directly, without the agency on the call.

How to structure the engagement once you've chosen

Don't sign a six-month contract with a team you've never worked with. Start with a small paid engagement — a discovery phase, an architecture review, or a first module — that produces something genuinely useful on its own. You'll learn more about how a team works in three weeks of real collaboration than in any amount of reference checking, and the cost of being wrong stays small.

Then insist on three things for the main build: a demo every two weeks, a preview environment you can click through yourself, and a named person you can call. Those three make problems visible early, which is the only reliable protection against a project quietly going wrong.

The uncomfortable summary

You cannot fully de-risk this decision by evaluating harder. What you can do is choose a team that makes problems visible quickly, structure the engagement so the cost of being wrong is small, and make sure you own everything produced. Do those three and a bad choice becomes recoverable — which is a more realistic goal than making a perfect one.