The website project that drifts is a classic. You hire a freelancer or a small agency, agree on “a modern site for the business,” and six weeks later you are on your fourth round of changes, the budget is gone and nobody is sure what was promised. Diagnose it honestly and the cause is almost never the developer’s skill. It is a request that never stated what the site had to do. This post lays out the symptoms, the root cause and a fix: a one-page requirements note you write before anyone quotes or starts.<\/p>\n
Look for these signs in your own history, or in a project that is currently struggling.<\/p>\n
Each of these has the same cause. The project has no shared description of the outcome, so everybody fills the gap with their own picture.<\/p>\n
“A website for my business” is a topic. A specification says what visitors should be able to do, what the owner must be able to change without help, which systems it connects to, by what date it goes live and how much can be spent. Without those, estimates are guesses and every change request is a negotiation. Planning documents that cover structure before building begins are common advice in this field; a step-by-step article on groundwork that precedes building a company website<\/a> goes through much of the groundwork that feeds a good note.<\/p>\n One sentence about what the site must achieve for the business. “Let visitors request a quote in under two minutes” beats “look professional.” If you have two goals, rank them.<\/p>\n Give the go-live date and what drives it, such as a campaign, a launch or a season. State whether it is fixed or flexible. Developers schedule real work around this, and an honest reason lets them warn you early.<\/p>\n State the range and what it should include: design, build, content entry, hosting, training, and a short support period. Leaving it out does not protect you; it makes quotes impossible to line up.<\/p>\n List the platform or CMS you already use or must use, who updates content, the languages needed, accessibility expectations, integrations with payment or email tools, and any data or privacy requirements. Say what you do not want, for example a rebuild of the logo. Pages that almost every business needs are listed in a structural guide to the pages every company site tends to need<\/a>; use it to decide which belong in your scope and which wait for a second phase.<\/p>\n Write acceptance tests in plain words. “A staff member can edit a service page and publish it without calling the developer.” “The contact form sends a message to our shared inbox and shows a confirmation.” “Pages load acceptably on a mid-range phone.” These become the checklist at hand-over, and they stop arguments about taste.<\/p>\n Include the current site address if one exists, what you like and dislike about it, two example sites you admire, and what happened in earlier attempts. Add who has to approve work. A hidden approver who appears at the end is one of the commonest causes of delay.<\/p>\nThe fix: a requirements note in six short sections<\/h2>\n
Outcome<\/h3>\n
Deadline and reason<\/h3>\n
Budget range<\/h3>\n
Constraints<\/h3>\n
What done looks like<\/h3>\n
Context a stranger would miss<\/h3>\n
Where to send the note<\/h2>\n