Agency or engineer, and how to tell which you need.
Both are legitimate. They fail in different ways, and the failure modes are predictable enough to choose between in advance. This page sets out the difference, says plainly where an agency is the better answer, and gives you the questions that separate a good one from a confident one. If you would rather judge on output, the work is here.
The retainer arrangement
The default way technical work is bought, and the one most businesses are still paying for.
One engineering practice
Sixteen services across Build, Grow and Scale, under senior engineering ownership and one accountable owner.
- Who builds
- Sold by a senior. Built by whoever is free that week.
- Who builds
- Scoped, written and reviewed under senior engineering ownership.
- Structure
- Several vendors, several invoices, no single owner.
- Structure
- Sixteen services, three pillars, one accountable owner.
- Deliverable
- A report, a deck, and a list of recommendations.
- Deliverable
- Working code, a documented deployment path, and a handover.
- Ownership
- Access through somebody else's accounts.
- Ownership
- The repository, the domains, and the analytics property.
- Performance
- Fast enough, measured on an office desktop.
- Performance
- Core Web Vitals as a build requirement, measured on mobile.
- SEO
- Rankings and traffic, summarised monthly.
- SEO
- Crawlability, indexation, and the code that causes both.
- AI search
- An add on line item, when it is mentioned at all.
- AI search
- GPTBot, ClaudeBot, PerplexityBot and Google-Extended, allowed by name.
- Proof
- Case studies you cannot open and screenshots you cannot check.
- Proof
- Software you can install today, and tools you can run on this page.
- Result
- Advice in a folder, and an invoice that repeats.
- Result
- A system in production, senior review behind it, and the means to maintain it.
Not sure which column your last project sat in?
Fifteen minutes, no deck. Bring the site, the stack, or the last invoice you were unhappy with, and we will tell you which column it belongs in and what it would take to move it.
Three situations where an agency is the better choice.
We would rather say this than have you find it out at month four. If your situation is one of these, hire the agency.
You need many disciplines at once, permanently
A brand refresh, paid media, PR, social, and a site rebuild running in parallel is a staffing problem. An agency already has those people and can put them on it this month.
The work is volume, not depth
Two hundred landing pages a quarter to a fixed template is a production line. Production lines want capacity and process, and a good agency is built to supply both.
You need cover, not a specialist
Holiday, illness, and turnover are somebody else's problem inside an agency. A single practitioner is a single point of failure, and for some organisations that risk is the deciding factor.
The pattern underneath all three is the same. Agencies are built for breadth and for capacity. When the constraint is how many hands you need, that is the right shape. When the constraint is how well one thing has to be built, it stops being the right shape, and the work quietly moves to whoever on the team is free.
Depth beats capacity on anything that has to keep working.
A brochure site can be produced. An application, an integration, or a search architecture has to be understood, and understanding does not survive being split across four people who each hold a quarter of it.
This is why the technical work reads so differently after handover. Code written by whoever was free is code nobody can explain a year later. That is a maintenance cost you pay forever, and it never appears on the original quote.
Search work has the same shape. Rankings can be reported by anyone. Crawlability, indexation and rendering are properties of the code, and they only improve when the person diagnosing them can also change them. The same is true of being citable by generative engines.
The question is not agency or individual. It is whether the person who understands the problem is the person allowed to fix it.
Five questions worth asking either one.
These work on us as well. If any partner cannot answer all five without rescheduling the call, that is the answer.
- Who writes the code, and can I meet them before I sign?
- The person in the pitch is often not the person on the keyboard. Ask for the name and the seniority of whoever will actually be doing the work, and ask what else they are on that month.
- What do I own at the end, and where does it live?
- The repository, the domains, the analytics property, and the deployment. If any of those sit inside an account you cannot access, you are renting your own business.
- What happens to performance after launch?
- Ask how Core Web Vitals are measured, on what device class, and whether a regression fails the build or just gets noticed later. Fast on a desktop connection is not an answer.
- How is this work made legible to AI search?
- Ask which crawlers are allowed by name in robots.txt, whether structured data matches what is visible on the page, and how the site would be cited rather than merely ranked.
- Can you show me something you built that I can open right now?
- Not a case study PDF. A URL, an app, or an extension. Anything that runs is worth more than any deck, because it can be checked. Ours are at /work and /free-tools.