Hiring agencies & developers

Judge on evidence, not on the proposal document.

• Open their past work on your phone. If their own clients' sites are slow or broken on mobile, yours will be too.
• Ask for two references you can actually contact, ideally from projects a year or more old. Recent clients are always happy; the question is how it aged.
• Read the proposal for specifics. Vague scope means vague delivery and an argument later.
• Confirm ownership of domain, hosting and code, in writing.
• Check who does the work. Some agencies sell you a senior and staff you with a junior.

The biggest predictor of a good outcome is how precisely they ask questions before quoting. Someone who quotes without asking anything has not understood the project.

It depends on the risk you least want to carry.

A freelancer is cheaper, faster to communicate with and often more invested. The risk is continuity: illness, a better contract or simply disappearing leaves you with a site nobody else understands.

An agency costs more and moves slower, but survives one person leaving, covers more disciplines and is easier to hold accountable contractually.

A small studio sits between the two and is where most small businesses land: direct contact with the person building it, but more than one person who knows the project.

Whichever you pick, insist on documented handover. That single requirement neutralises most of the continuity risk.

Five things, in the order they predict a good outcome:

1. How they scope. Do they ask about your customers and your process, or only about pages and colours?
2. What is written down. Deliverables, timeline, revision rounds and price, all in the proposal.
3. Technical standards they name without prompting — performance targets, SEO foundations, accessibility, security updates.
4. Post-launch terms. What happens in month two, and what it costs.
5. Their own site. Slow, outdated or unindexed is a direct signal.

Ask one more question: what would make you turn down this project? An agency that has never said no to anything will say yes to something they cannot deliver.

Walk away if you see these:

• A quote without questions. Nobody can price a project they have not understood.
• Guaranteed number-one rankings. Nobody controls Google. This one is disqualifying on its own.
• Registering the domain in their own name, or refusing to say who owns the code.
• No written scope, only a total price.
• Full payment up front from someone with no track record.
• Portfolio links that are dead or lead to sites that no longer exist.
• Vagueness about maintenance. "We'll take care of it" is not a term.

One yellow flag is worth discussing. Three means you are about to pay for a lesson instead of a website.

Structure the hire so reliability is verifiable rather than promised:

• Start with a small paid task before the full project. A day's work tells you more than three meetings.
• Pay in phases tied to deliverables, never fully up front.
• Agree a communication rhythm in writing — a weekly update, even a short one.
• Require a handover document: how to edit, where things live, what the passwords are.
• Keep the domain and hosting in your own name from day one.

And watch how they behave when something goes wrong in the small task. How someone handles a mistake is far more informative than how they handle a smooth week.

Because the work involves several distinct skills, and the cost of learning them is usually higher than the cost of buying them.

A business website needs design, front-end code, server configuration, SEO structure, performance work, security and accessibility. Doing it yourself on a builder is genuinely viable for a simple brochure site — and if that is your situation, do that and spend the money on customers instead.

Delegating makes sense when the site has to perform: rank, convert, integrate, scale. At that point the mistakes are expensive and invisible until they are not.

The honest test: if you cannot name what the site must achieve in numbers, you are not ready to hire anyone yet.