Ten mistakes we see in website procurement

We have worked on website projects for more than twenty years and read more requirements specifications than we can count. Some are clear and well thought out. Many are not. And those that fall short tend to do so in the same ways, regardless of the sector, the size of the project or whether the procurement is public or private.

This article looks at those mistakes. Not to point the finger at clients — often, we agencies should have asked the questions earlier — but because these mistakes are avoidable, and they cost more than anyone expects.

1. You start with the solution, not the goal. Write down the goal first and make sure every feature supports it.
2. You ask for a quote before you know what you need. Map out the workflow before starting procurement.
3. The specification gets too detailed too soon. Pin down goals, budget, workflows, integrations and legal requirements. Leave the design open.
4. The ChatGPT wish list. Ask who in your organisation needs each requirement. If no one can answer, remove it.
5. Page 3 says one thing, page 5 says another. Have one person read the whole document in one sitting before sending it out.
6. Three people, three specifications, one document. Give one person ownership of the document and the authority to say no.
7. You want a fixed price for a vague brief. Write a clear specification, or commission a discovery phase first.
8. The requirements do not reflect how website projects work. Let the people who will work with the website review the requirements before issuing the tender.
9. Price matters most. Compare the total cost over three years, including maintenance and ongoing development.
10. SEO is left too late. Take stock of what works today and plan redirects before design begins.

Almost every mistake below is a variation on the same problem:

The agency is asked to price the project when it knows the least about it.

When the uncertainty lands with the agency, it has three options: guess low and make up the difference through extra work later, guess high and build in a safety margin, or decline.

The client loses out in all three cases.

We have grouped the mistakes by where they happen in the process: before the document is written, in the document itself, when bids are assessed and when the old website is replaced.

The specification focuses on features: we want a slider and a chat function. It says nothing about what the website should achieve — more enquiries, fewer calls to customer service, higher conversion rates in the online shop.

That is understandable. Features are tangible and easy to point to on a competitor's website. Setting goals means first deciding what your website is for.

But without goals, the agency builds what was ordered, not what is needed. And there is no way to measure whether the new website is better than the old one, because no one has defined a conversion or decided who will set up the tracking.

What to do: write down the goal first and make sure every feature supports it. Include a chat function because it reduces calls to customer service, not because a competitor has one. Cover measurement in the same section: which tools, which conversions and who is responsible.

This also gives the agency, which works with these challenges every day, a chance to suggest solutions you may not have considered.

You ask for a quote for services you are not sure you need. The website's workflow has not been defined: what should visitors do, where do enquiries go, and which systems need to connect?

This often happens when a budget or deadline creates pressure, and procurement starts before the internal groundwork is complete.

The problem is that integrations — connections to your CRM, business management system, booking system or inventory — are the most expensive and risky part of a website project. When these are unknown, the agency is pricing a website that may not be the one it ends up building.

What to do: map out the workflow before starting procurement. It does not have to look polished. The visitor lands here, does this, and that triggers this action in our CRM. If you cannot map out the workflow, you are not ready to ask for a fixed price. Instead, treat integrations as a separate part of the project for the agency to quote on later, once it has mapped out the workflow with you.

The opposite happens too. Everything has to be pinned down in advance in a lengthy specification: every page, every field, every button. It feels reassuring, and in public procurement it is often a requirement.

But that locks the project down before a single visitor has tested anything. There is no room to learn from user testing and change direction, and every change becomes an extra charge. The website is built around assumptions about visitor behaviour, not how visitors actually behave.

What to do: pin down what must stay fixed — goals, budget, workflows, integrations and legal requirements. Leave the design open, and specify that it must be tested and can be adjusted.

More and more of the specifications we receive are largely written using ChatGPT. They look professional, cover everything and read well. But no one on the client's side can explain why the requirements are there or which ones are actually needed.

AI is a useful tool, and we use it ourselves every day. But it answers the question what could a website include, not what do we need. When every requirement looks equally important, the agency prices them all. The quote ends up costing more than you need to spend, or the wrong things get cut when the budget falls short.

What to do: by all means use AI to help you cover everything, but review each requirement and ask: who here needs this, and what happens if we do not have it? If no one can answer, remove it.

The specification contradicts itself. One section calls for a simple system the marketing team can manage on its own; another requires integrations that only a developer can maintain. The budget on one page does not match the features on the next.

This happens when a document has grown over time and no one has read it from start to finish before sending it out. The agency then has to choose an interpretation, and different agencies choose differently. The result is quotes that cannot be compared.

What to do: have one person read the whole document in one sitting before sending it out. Wherever requirements conflict, remove one or make the priority clear.

Once, a specification was so hard to understand that we had to use AI to summarise it and work out what the client wanted. It turned out that three people had each written their own specification in the same document, without anyone bringing them together.

No one had been given ownership of the document. Everyone contributed; no one made decisions. The agency had to guess whose requirements took precedence, and whoever had written least clearly risked getting the least of what they needed.

What to do: give one person ownership of the specification and the authority to say no. And try this simple test: if you need a summary to understand your own document, the agency will too. Write it yourselves and include it.

Your brief is only a few lines long, but you want a fixed price. At the same time, you expect a lot from the agency: references, guarantees and a delivery schedule.

This is the common problem in its purest form. A fixed price needs a well-defined brief. Without one, the price is either a guess or a safety margin that you pay for.

What to do: choose one of two options. Invest time in a clear specification, or commission a discovery phase first and ask for a fixed price afterwards. Both cost less than paying for the agency's uncertainty.

We see this particularly in public procurement. The requirements for the supplier and the project are theoretical. They are written to be comprehensive and legally watertight, rather than grounded in how a website project is actually delivered.

Often, the tender is written by a procurement officer or based on a template, rather than by the people who will use the website every day. Agencies that would be a good fit are then ruled out on formalities. The winner has shown that it can write a bid, not necessarily that it is the right agency to build and maintain the website.

What to do: let the people who will work with the website review the requirements before issuing the tender. Every requirement should link back to a real need.

The lowest bid wins. Price is compared, but not what is included, what happens after launch or how long the platform will last.

Price is the only thing that is easy to compare, especially when the specification is vague and the bids address different things. But the lowest bid often costs more in the long run: through extra charges for things left out of the quote, poorer quality or a platform that needs replacing after a couple of years.

Many specifications also stop at launch day. They say nothing about who handles updates and backups, or who responds when something breaks.

What to do: compare the total cost over three years, including maintenance and ongoing development. And ask every supplier one simple question: what happens if the website goes down on a Friday evening? The answer says a lot about how seriously the agency takes operations and security.

Many organisations lose traffic from Google when they replace their website. No one has planned the redirects, the URL structure or how to migrate content that ranks well today.

SEO is treated as something to do after launch, not as part of the build. The specification describes the new website but says nothing about the old one. Traffic can plummet within a week of launch and take a long time to recover, if it ever does.

This is often the most expensive mistake of all, and the last to show up.

What to do: require an audit of what works today: pages that rank, keywords you appear for and forms that convert. Require a plan for redirects and URLs before design begins.

Mistakes 3 and 7 seem to contradict each other. A specification can be too detailed, and it can be too vague.

There is no contradiction, because what matters is what it locks down.

A good specification is firm on what the website should achieve and which systems it should connect to, but open on how it should look. Most do the opposite: vague goals and detailed features.

It would be easy to put all the responsibility on the client. But many of the mistakes above persist because we agencies let them.

We should ask the questions earlier: what is the goal, what does the workflow look like, who owns the decision? We should refuse to give a fixed price for something that cannot be priced, rather than guessing and hoping for the best. And we should suggest a discovery phase more often, even when that means the quote takes longer.

Procurement works better when both parties know what is being built before the price is set. That is really the whole point of this list.

Our guide Website procurement takes you through the whole process, with a checklist of the ten areas a requirements specification should cover. Download the guide