The single most useful thing you can do before contacting a developer is write one page about the project. Not a specification, not a design, just the answers to the questions every competent developer will ask anyway. It gets you quotes you can compare, it flushes out assumptions early, and it tells a good agency that you are serious.
Here is what goes in it.
1. The business, in three sentences
What you do, who your customers are, and what makes you different. Developers who understand the business make better decisions on the hundred small things you will never discuss.
2. The goal, in one sentence
"We want more enquiries from commercial clients." "Our staff spend two hours a day re-typing orders." "Customers keep calling to ask where their order is." One sentence, about the outcome, not the technology. If you cannot write this sentence yet, the project is not ready to be quoted.
3. Who will use it
Customers, prospects, staff, partners. For each: roughly how many, on which devices, how often. "Twelve field engineers on Android phones, several times a day" leads to a different proposal than "occasional visitors on a laptop".
4. What it must do, and what would be nice
Two lists. Must-haves are the things without which the project fails: "take bookings with a deposit", "show customers their order status". Nice-to-haves are everything else. Being honest about which list an item belongs to is the single biggest influence on getting a sensible price.
5. The current situation
- Do you have a website or system now? What is wrong with it?
- Where is it hosted, and do you have access?
- Which content exists already (text, images, product data) and which has to be created?
- Which other systems are involved: CRM, accounting, payments, stock, calendar, mailing tool?
The last point matters more than people expect. Integrations shape the design; see our guide to integrations if you are unsure what to list.
6. Content and who writes it
Websites are late more often because of missing text and images than because of code. Say who will write the content, whether photography is needed, and whether the site must work in more than one language.
7. References and taste
Two or three sites or apps you like, with a sentence on why. Also one you dislike, with why. "We like the clarity of this one but find that one cluttered" is far more useful than a mood board.
8. Constraints
- Budget range. Even a wide range ("between X and Y") lets a developer propose the right scale instead of guessing.
- Timing. A real deadline (a launch, a season, a contract) or "no fixed date". Both are fine; pretending there is a deadline when there is not causes bad decisions.
- Legal and compliance. Privacy requirements, accessibility expectations, industry rules, data that must stay in a particular region.
9. How you will know it worked
Enquiries per month, hours saved, orders completed without a phone call, fewer support tickets. One or two measures. They keep everyone focused during the build and give you something to check afterwards.
10. Who decides
The person who signs off on decisions, and how quickly they can respond. Projects stall on approvals more than on anything else.
What you do not need to include
- A technical specification. The developer's job is to propose the technology.
- Finished designs. References and taste are enough; design is part of the work.
- Every page or screen. The must-have list and the users cover it.
- Exact wording. Content comes later.
The template
Copy this into a document and fill in each line. Short answers are fine.
Business: what we do, for whom, what makes us different
Goal: one sentence about the outcome
Users: who, how many, which devices, how often
Must-haves: ...
Nice-to-haves: ...
Current situation: existing site/system, hosting, access, content, other systems
Content: who writes it, photography, languages
References: 2–3 we like and why, 1 we dislike and why
Budget range: ...
Timing: deadline or none
Legal/compliance: privacy, accessibility, data location
Success measures: 1–2 numbers
Decision maker: who, and typical response time
A brief like this takes an hour to write and saves days of back-and-forth. If you would like to send us one, the enquiry form accepts a PDF or document attachment, and we will come back with questions rather than a guess.