Most web projects that get complicated don’t do so because of technical problems, but because nobody made clear from the start what had to be built and why. A well-prepared brief is the most profitable document in the whole project: it takes a few hours and can save weeks.
What a brief is (and what it isn’t)
A brief is a short document that explains what your business needs, not how it should be done technically. You don’t need to know anything about programming to write one. In fact, the more it focuses on goals and the less on specific solutions, the more useful it will be to whoever has to build it.
What it isn’t: a list of features copied from a competitor’s website, or a visual description along the lines of “I want something modern and clean”.
The 6 questions it should answer
- What do you want to achieve with the website? More bookings, more enquiries, selling online, fewer repetitive phone calls… One main goal, measurable if possible.
- Who is going to use it? Local customers, tourists, businesses, internal staff. Language, usual device and technical confidence change many decisions.
- What does a user need to be able to do? Look up information, book, pay, register, download documents. List them as actions.
- What does your team need to be able to do? Edit text, manage bookings, view orders, export data. This is often forgotten and defines much of the backend.
- Which systems does it need to connect to? Payment gateway, CRM, invoicing software, calendar, email marketing tools.
- What timeline and budget are you working with? Even a rough range. Without that reference, any proposal is a shot in the dark.
What helps a lot (and hardly anyone includes)
- Examples of websites you like, and why. Not to copy them, but to understand your preferences. “I like how quickly you can book on this one” says far more than “I like this one”.
- What doesn’t work on your current website. If you already have one, its problems are the best clue to what needs prioritising.
- Available content. Do you have copy, professional photos, a good-quality logo? Or do they need creating? This directly affects timelines.
- Who makes the decisions. If several people are involved, it’s worth knowing who approves each phase to avoid bottlenecks.
Common mistakes when preparing a brief
Defining the solution instead of the problem. “I need an app” is a solution. “My customers call me ten times a day to ask about availability” is a problem, and the best solution might be a simpler one.
Asking for everything in the first version. It’s better to launch the essentials done well and expand later than to try to cover every case from day one. Separate the must-haves from the nice-to-haves.
Leaving out expected growth. If in a year you plan to open another location, sell online or work in another language, say so now. It shapes the architecture, and changing it later costs much more.
A brief is a conversation, not a contract
The document doesn’t have to be perfect. Its job is to start the conversation from common ground. A good developer will ask questions, spot gaps and suggest alternatives. What matters is that both sides start out talking about the same project.