ERY SOFTWARE6 min read
The first message you send to a development team shapes everything that follows. A vague message gets a vague reply: a generic price range, a list of questions, or a template proposal. A clear brief gets you a conversation about your actual problem. The good news is that a clear brief does not need to be long, technical or finished.
Start with the problem, not the feature list
Most briefs begin with features: a login, a dashboard, a blog, a payment page. Features matter, but they are answers. The question behind them is more useful to the team you are talking to. Write one or two sentences about what is not working today, or what you want to become possible.
- "Customers call us to ask about prices because the website does not explain our packages."
- "We manage bookings in a spreadsheet and double-book rooms every month."
- "Our current site looks outdated and does not work well on phones."
A sentence like this lets the team suggest a simpler solution than the one you had in mind, or warn you early that the real work is somewhere else.
Say what success looks like
Goals turn a project from "build a website" into something you can evaluate. You do not need numbers. It is enough to say which outcome matters most: more enquiries, online sales, a more credible brand, fewer manual tasks, or content your team can update without help. If several goals compete, say which one wins. That single decision removes a lot of guesswork from design and scope.
Describe where you are starting from
Starting from scratch, redesigning something that exists and extending a working product are three different projects, even when the end result looks similar. If something already exists, mention it and share a link or screenshots. Note what you want to keep: content, data, URLs that bring visitors from search engines, integrations your team depends on.
Timeline and scope: rough is fine
It is normal not to know your budget in detail. A rough scope band is enough to start: a focused site, a medium-sized platform, or a long-term product. The same goes for timing. Is there a real deadline, such as a launch event or a season, or is the date flexible? Real deadlines change how a project is planned, so they are worth mentioning explicitly.
Share examples — and say why you like them
Links to sites or apps you like are useful, but only with a short note. "I like how clear the pricing page is" tells the team much more than a bare link. Examples you dislike are just as helpful.
What you can leave open
You do not need to choose technologies, write a full specification or design screens. A good team will ask about these during discovery and explain the trade-offs in plain language. It is better to write "not sure yet" than to guess; a guess written down in a brief tends to become a requirement nobody questions.
A simple template
- What kind of project is it? (website, custom software, product, online store…)
- What should it achieve? Which goal matters most?
- Where are you starting from? (new, redesign, extend)
- Is there a deadline, and roughly what scope do you have in mind?
- Examples you like or dislike, with one sentence each.
- Anything that must be kept or integrated.
Our contact form follows the same structure, so you can use it as the template. After you send it, the next step is a discovery conversation and then a written proposal; nothing is committed before you approve it.
Have a project in mind?
Send us a brief