Most businesses choose a development company by looking at portfolios and comparing quotes. Both are reasonable instincts, and both tell you remarkably little about what the next four months will be like.
Contents
- Start with whether they ask you questions
- Ask what they would refuse to build
- Look at the portfolio differently
- Separate design capability from development capability
- Ask how UX decisions get made
- Check the SEO foundations, not the SEO promises
- Find out who owns what
- Ask what editing a page will be like
- Talk about what happens after launch
- Read the proposal for what it does not say
- On price
- A short list of questions worth asking
- The honest summary
A portfolio shows you what a company was allowed to do for someone else, filtered through whatever that client approved. A quote shows you what someone thinks the work costs before they understand your business. Neither predicts whether the finished site will do anything useful for you.
Here is what we would actually look at, including the parts that are inconvenient for us to say.
Start with whether they ask you questions
The single most reliable signal in a first conversation is the ratio of questions to pitching. A company that spends the first meeting presenting its own credentials is telling you how the project will run: they will build what you asked for rather than what you need.
Good questions at this stage sound almost annoying. What happens in your business when a lead comes in? Who actually decides? What did you try before? Which of your competitors do you lose to, and why? None of that is about the website, which is exactly why it matters.
Ask what they would refuse to build
Any company will tell you what it can do. Fewer will tell you what they think is a bad idea, and that is the more useful answer.
If you describe a project and nobody pushes back on any part of it, one of two things is true: your plan is perfect, or they are not thinking about it. Over the length of a real project, the second is considerably more common.
Look at the portfolio differently
Do not scroll the portfolio looking for sites you find attractive. Look for these instead:
- Variety of problem, not variety of colour. Six beautiful sites that all solve the same problem tell you about their taste, not their range.
- Sites still live and still current. Open them. A portfolio full of sites that have since been replaced or gone stale says something about what happens after launch.
- Work in your rough complexity band. A studio that makes gorgeous single-page sites may genuinely struggle with a 400-page multilingual build, and vice versa.
- Evidence of the unglamorous parts. Ask to see a CMS they built. That is where corner-cutting hides.
And if a portfolio contains concept work, it should say so. Presenting self-directed concepts as client engagements is a small dishonesty that tells you how the larger ones will be handled.
Separate design capability from development capability
These are genuinely different skills and plenty of companies are strong in one and weak in the other. The failure mode is invisible until it is expensive.
A design-led company with weak development produces a beautiful site that is slow, hard to maintain, and fragile when your team edits it. A development-led company with weak design produces a robust site nobody wants to use.
Ask who does each. If the answer is vague, or if design is done in-house and development is quietly subcontracted, you need to know that now rather than in month three.
Ask how UX decisions get made
This is the question that separates a company with a method from one with a style.
There should be an answer involving research, analytics, structure and testing, and it should come before any discussion of visual design. If information architecture is described as something that happens during design, the site will be organised around what looked good in a layout rather than around what people came to do.
If the structure is decided by the design, the design is deciding what your business is about.
Check the SEO foundations, not the SEO promises
Almost every development company says it builds "SEO-friendly" sites. The phrase is close to meaningless. What you want to know is whether the technical foundations are part of the build or an upsell afterwards.
- Semantic heading structure and markup
- Clean, stable URL structure
- Server-rendered content that search engines can read without executing JavaScript
- Core Web Vitals treated as a build requirement rather than a later fix
- Structured data where it genuinely applies
- A redirect plan if anything is replacing an existing site
Be suspicious of anyone who guarantees rankings. Search results are decided by systems no agency controls. A responsible company will describe the work and the measurement, not promise a position. Our own SEO page says the same thing at more length.
Find out who owns what
This gets skipped and then becomes painful. Before signing anything, establish:
- Who owns the design files and the code when the project ends.
- Who owns the domain and the hosting account — it should be you, in your name, with your billing.
- Whether the CMS is something you can hire for, or proprietary to that company.
- What happens to the site if you stop working with them.
None of these need to be adversarial conversations. They simply need to have happened. A company that answers them clearly is one that expects the relationship to end well.
Ask what editing a page will be like
You will live with this for years. Ask to be shown the CMS of a site they built — not a demo, a real one — and ask specifically which parts of a page are editable and which are structural.
If updating a paragraph requires emailing the agency, the site will be out of date within a year. That is not a hypothetical; it is the single most common reason a two-year-old site feels stale.
Talk about what happens after launch
Launch is a beginning, and a company that treats it as the end of the relationship is giving you a site that peaks on day one.
Ask what support looks like, what it costs, and whether it is optional. There is nothing wrong with a company that hands over cleanly and lets you take it in-house — that is a legitimate outcome. What matters is that the answer is explicit rather than discovered later. Ours is on the website management page.
Read the proposal for what it does not say
A good proposal is specific about scope, and specific about what is excluded. Vagueness in a proposal is not generosity; it is where the change requests will come from.
Key points
- Number of unique page templates, not number of pages
- Who writes the content, and when it is needed
- What "responsive" covers — which breakpoints are actually designed
- Whether the quote includes tracking and analytics setup
- What is explicitly out of scope
- What happens, commercially, when scope changes
On price
The cheapest quote is usually cheapest because it assumes less. That is not dishonest, but it does mean you are comparing different projects and calling it a price comparison.
The useful question is not "what does a website cost" but "what does this scope cost, and what would change the number". Any company that will not answer the second half is quoting a guess.
A short list of questions worth asking
- What would you need to know about our business before you could quote this properly?
- What part of this project do you think is the riskiest?
- Who specifically will do the design, and who will do the development?
- Can I see a CMS you built, on a real site?
- How is the information architecture decided, and when?
- What happens to our search visibility during the switchover?
- What does support cost after launch, and is it optional?
- What do we own when this ends?
The honest summary
You are not really choosing a portfolio. You are choosing a group of people to make several hundred small decisions on your behalf over several months, most of which you will never see.
Choose the ones who asked the best questions, disagreed with you about something, and were specific when it would have been easier to be vague.