How to Prepare Requirements Before Hiring a Web Developer

Most website projects that go badly did not go wrong during the build. They went wrong at the brief, where "a simple website for my business" meant five pages to one side and twenty-five to the other, and nobody found out until the invoice arrived.

You do not need a technical specification. You need roughly two pages of plain writing that answer the questions any competent developer will ask anyway. Here is what to put in them.

Start with the outcome, not the features

Write one or two sentences describing what should be different once the site is live. "I want customers to be able to see our full product range and enquire without messaging us on Instagram" is a useful brief. "I want a modern, professional website" is not — it is true of every project ever commissioned.

Then name how you will know it worked: enquiries arriving by email, appearing in search for a specific phrase, spending less time answering the same question. A developer who knows the target can tell you when a requested feature will not move it.

List the pages you think you need

A rough list is enough, and it is the single most useful thing you can bring. Page count is the biggest driver of both cost and timeline, so an approximate list turns a vague quote into a real one.

• Home
• One page per service or product category you sell
• About
• Work, portfolio or gallery, if you have examples to show
• Contact
• Anything specific to your business — booking, pricing, locations, downloads

If you are not sure, start from the questions customers ask before they buy. Each recurring question is usually a section, and each cluster of questions is usually a page.

Do a content inventory — honestly

Content is the most common reason a project stalls, and it almost always sits with the client rather than the developer. Go through your page list and mark each item: written, needs writing, or needs a decision.

• Service descriptions — do they exist in writing anywhere today?
• Photographs — real ones of your work, premises or team
• Logo files — ideally vector (.svg, .ai or .eps), not a screenshot
• Any existing brand colours, fonts or guidelines
• Legal text — or a note that you need help drafting it

Separate must-have from nice-to-have

Write your feature list in two columns. This one habit prevents most budget arguments, because it makes trade-offs a conversation rather than a surprise.

Must-have

Things without which the site cannot launch. An enquiry form. Mobile support. The ability to update prices yourself, if prices change monthly.

Nice-to-have

Things you would like if budget allows: a blog, live chat, multi-language support, customer accounts. Being explicit that these are optional lets a developer quote a base version plus options, instead of one large number you cannot interrogate.

Describe the functional bits properly

Anything that is not just a page of text needs a sentence or two more. These are the features that quietly multiply cost, so they are worth spelling out.

• Online payments — which gateway, and do you already have a merchant account?
• Accounts and logins — who logs in, and what can each type of user do?
• Booking — do you need availability and calendar rules, or just a request form?
• Product catalogue — roughly how many products, and do they have variants?
• Integrations — accounting, CRM, email marketing, inventory or anything you already run
• Content editing — which parts do you genuinely want to edit yourself?

That last point is worth thinking about carefully. Making everything editable adds cost and complexity; making nothing editable means paying for every small text change. Most businesses want a small set of frequently-changing things under their own control. Our Custom Software Development and E-commerce Development pages set out what these features usually involve.

Say what already exists

If you have a current website, this section saves everyone time and prevents an expensive surprise.

• The current address, and what is wrong with it in your words
• What is built on — even "I do not know, someone else set it up" is useful
• Who holds the domain, hosting and DNS access
• Whether it currently receives traffic or enquiries you cannot afford to lose
• Any pages that must keep their existing addresses

Give a budget range, not a poker face

Withholding budget feels like negotiating leverage. In practice it wastes both sides’ time, because scope and budget are the same conversation. A range is enough: it tells a developer whether to propose a focused five-page site or a custom application, and it lets them tell you honestly if what you want does not fit.

The same applies to timing. If there is a real deadline — a trade show, a season, a funding milestone — say so and say why. If there is not, say that too; invented urgency leads to rushed decisions.

Questions worth asking any developer

Once you have your brief, these questions separate proposals quickly.

1. 1What is included in the quote, and what would be charged separately?
2. 2Who owns the code, the design files and the accounts at the end?
3. 3How many revision rounds are included, and what counts as a new round?
4. 4What happens after launch — is support included, and for how long?
5. 5What do you need from me, and by when, to keep the timeline?
6. 6Can I see something you have built that is still live?

A brief that fits on two pages

Pull it together in this order and you are ready to approach anyone: what the site should achieve, the page list, the content you have and do not have, must-haves and nice-to-haves, the functional features described in plain words, what already exists, and your budget and timing.

That is enough for a developer to quote accurately and for you to compare quotes on the same basis. If you would like a second opinion on your brief before you send it out, send it over — we will tell you what is missing whether or not we end up doing the work.