When you commission technical work without a technical background, the first thing you usually do is collect screens. You screenshot sites you like, sketch a menu structure and list the pages you need. That is good preparation. Hand over only that, though, and you will get a fast quote and a result that misses.
The reason is simple. A screen is an answer; a requirement is a problem. Give someone only the answer and they cannot know why it has to be that way, so they build exactly what is drawn — and when it is built, you say it is not what you had in mind. That gap is not a failure of skill. It is a failure of what was handed over.
What actually happens when you hand over screens
Give a developer five reference sites and they will infer what the five have in common. Sometimes the inference is right, but usually the thing you liked and the thing they read are different. You picked a page because it looked like enquiries would arrive; they read it as a colour palette and a spacing rhythm.
The bigger problem is the conditions you did not mention. That you need to edit the copy yourself afterwards, that the pages must be findable in search, that the existing domain has to stay — none of that appears in a screenshot. These conditions tend to surface when the work is nearly finished, which is exactly when reversing them costs the most.
Three headings on one page
You do not need a formal specification. Three headings will do, each written in plain sentences.
Write the goal in the language of your business. Not “we need a contact form” but “we want at least five consultation enquiries a week and right now everything arrives by phone”. Framed that way, a good supplier can propose something other than a form.
List only constraints that genuinely cannot move: the domain already in use, data that cannot be migrated, the areas your own team must be able to edit, a budget ceiling, a date something is tied to. Constraints stated early get priced in. Constraints stated late become variations.
Acceptance is the idea this series keeps returning to: writing down in advance what you will look at to decide the work is finished. Without it, handover turns into an exchange of impressions. Part four covers how to write it properly.
The same request, written two ways
“Make the home page look sophisticated” is not a requirement. Sophistication cannot be judged, so nobody can tell when it has been reached.
The same request can be written like this. Goal — a first-time visitor understands what we do within five seconds. Constraint — we must be able to edit the copy ourselves, and it has to read well on a phone first. Acceptance — show the first screen to three people outside our industry and ask what the company does; all three get it right.
That third line matters most, and it helps the supplier as much as you. Instead of an open-ended stream of revisions there is a condition that can be met. A good requirements page protects both sides of the table.
What to send alongside the quote request
Three extras raise the accuracy of any quote considerably: your current site address if you have one, the type of hosting you are on, and a list of what you can prepare yourselves. The last one matters more than people expect — whether you supply the copy and images changes the number substantially.
We are a supplier ourselves, so we hold to the same standard. What we do and explicitly do not do is written as scope and exclusions on the optimization program page, and the working procedure is published step by step on our process page. When you receive a quote, the first check is whether those two things exist as documents at all.
Next part
Once the requirements go out, a quote comes back. The next part is how to read it — there are three things to look at before the number.