You have spoken to a couple of developers and each conversation went the same way. You explained your business, they asked thirty questions, you answered half of them from memory, and a week later the quote came back based on what they thought you meant. Now you are not sure the two quotes are for the same website.
A website requirements document fixes that. It is a few pages, written by you, that every developer reads before quoting. It does not need technical language. It needs your decisions written down in one place, so that the quote, the design and the final site are all built from the same starting point. In effect it is a website brief for a developer, written once and sent to everyone you ask to quote.
What a website requirements document is, and is not
It is a description of what your business needs the site to do, who it is for, what goes on it, and what you already have. It is not a design, a technical specification or a contract. You are not expected to choose fonts or name plugins. A good developer will translate your requirements into those decisions.
The test of a useful document is simple: could two developers who have never met you read it and quote for roughly the same website? If yes, it is doing its job.
Section 1: Your business in a paragraph
Write what you do, where, and for whom, as you would explain it to a new staff member. Include anything that makes you different from competitors and anything a visitor must understand within seconds of landing.
Example: “We are a family-run physiotherapy clinic with two locations in South Kolkata. Most patients are referred by doctors or come after a sports injury. People usually want to know whether we treat their condition, where we are, and how to book.”
Section 2: What the site must achieve
Pick one main action you want visitors to take and, at most, two secondary ones. Calls, WhatsApp messages, form enquiries, bookings, purchases, visits to the shop. Be specific about where enquiries should go: which email address, which phone, which person reads them.
This matters more than any other section. A site built to collect bookings is laid out differently from one built to sell products, and the developer needs to know which one you are asking for.
Section 3: Who visits and what they need
Describe your two or three main types of visitor. For each, write what they are looking for and what might stop them contacting you.
- Existing customers checking opening hours or a phone number
- New customers comparing you with competitors
- Job applicants, suppliers or partners, if relevant
Mention languages if some visitors prefer Bengali, Hindi or another language, and mention if many visit from outside India.
Section 4: The page list, with content status
This is the section developers price from. List every page you want, and next to each, say whether the content exists.
| Page | Purpose | Text | Images |
|---|---|---|---|
| Home | Who we are, main services, how to book | Draft ready | Need photos of clinic |
| About | Team, qualifications, locations | Not started | Team photos available |
| Services (one per condition) | What we treat and how | Notes only | None |
| Contact | Map, hours, form, WhatsApp | Ready | Not needed |
Be honest in the status columns. A developer who knows you need help with text will either quote for writing it or tell you to start now. One who assumes the text is ready will find out halfway through the build. If you are writing it yourself, our guide on writing content for each page is a good place to begin.
Section 5: Features, split into must-have and nice-to-have
List each function the site needs as its own line, then sort them into two columns.
Must-have: things the site cannot launch without. A contact form, click-to-call, a map, an enquiry form that emails two people.
Nice-to-have: things you would like but could add later. A blog, a newsletter sign-up, an online booking calendar, a second language.
The split does two useful jobs. Developers can quote the must-haves firmly and price the rest as options, and you have a ready-made list of what to defer if budget or schedule gets tight. Separating the two also has a big effect on how long the project takes, because nice-to-haves are where schedules stretch.
Section 6: Systems the site has to work with
Write down anything already in your business that the site must connect to or sit alongside:
- Payment gateway, if you already have an account
- Booking or practice management software
- Accounting or inventory system
- Email marketing list
- Google Business Profile, social media accounts
- Business email on your domain
Name the actual product where you know it. “We use Zoho Books” is more useful than “we have accounting software”.
Section 7: Who will update the site after launch
This shapes how the site should be built. If a staff member will add blog posts and change prices weekly, the developer needs to make those tasks easy and train that person. If nobody will touch it except through a developer, the build can be simpler. Write down who, how often, and what kind of changes.
Section 8: Accounts and access you already have
List the domain name, where it is registered, who holds the login, and the same for hosting and any existing site. If you are not sure, write “not sure”. Missing access is a frequent reason launches stall, and finding it early is far easier than finding it on launch day.
Section 9: Examples, with reasons
Add two or three websites you like and one or two you dislike. For each, write one sentence about why. “I like how this clinic shows prices for each treatment” helps a designer. A list of links with no reasons does not, because they cannot tell whether you liked the colours, the layout or the photos.
Section 10: Budget and constraints
Give a budget range if you have one. Developers can then suggest what fits rather than quoting a wish list you cannot afford. If you are not sure what is realistic, the website cost calculator gives a starting figure, and the guide to the cost of website development in India explains what moves the price.
Also note any hard constraints: an event the site must be live for, a brand guideline you must follow, a regulator’s rules about what you can claim, or a preference for WordPress because you have used it before.
Who should write it?
The person who will approve the finished site, ideally. If that is you, write the first draft yourself, even roughly, then ask one colleague who deals with customers to read it and add what you missed. Front-desk staff and salespeople often know the questions customers actually ask far better than owners do, and those questions are exactly what the site should answer.
How long should a website requirements document be?
For a small business site, a few pages is plenty. Short sections with plain sentences beat long paragraphs. Bullet points are fine. Spelling mistakes do not matter. What matters is that a reader finishes it knowing what to build.
A fill-in template
Copy this into a document and answer each line:
- Business name, what we do, where, for whom
- Main action we want visitors to take; where enquiries should go
- Main visitor types and what each needs
- Page list, with text and image status for each
- Must-have features
- Nice-to-have features
- Systems to connect or keep in mind
- Who updates the site, how often, what kind of changes
- Domain, hosting and existing site: where and who has access
- Sites we like and dislike, with reasons
- Budget range and any fixed dates or constraints
- Contact person for decisions and approvals
Common mistakes in a website brief for a developer
- Describing the look instead of the job. “Modern and clean” means something different to everyone. Describe what the visitor should do.
- Listing every possible feature as essential. Then every quote is expensive and none can be compared.
- Leaving out who approves. Developers plan differently for one decision-maker than for a committee.
- Sending it to some developers and not others. Send the same document to everyone, or the quotes will not be comparable.
- Treating it as fixed forever. Update it after the first conversations, then send the revised version to anyone still quoting.
Agencies that brief outside developers use a slightly different format, covered in our guide to briefing an outsourced developer; for an owner commissioning a whole site, the sections above are what matter.
If you write one and would like an opinion on it, send it to our website development team. We can read it, ask about anything that is unclear, and quote against it.
Next in this series: Website Development Contract: Clauses Owners Need
