Most first messages I receive about a project are one line long: "We want an app like X, how much?" That is a natural way to start, but no developer can give you a meaningful answer to it. The same sentence can describe a project of a few weeks or of many months.
A good brief changes that. It does not need to be technical or long. Two or three pages written in plain language let a developer understand what you need, ask the right questions and give you a realistic plan. It also forces you to make decisions early, when they are cheap.
Here is what to put in it, and a template at the end.
1. The problem, in two sentences
Start with the problem the app or website solves, and for whom. Not the features.
"Our customers book cleanings by calling or messaging us on WhatsApp. We lose track of slots, double book staff and spend hours every evening confirming tomorrow's schedule."
This tells a developer more than a list of screens would. Every later decision can be checked against it.
2. Who the users are
List each type of user and what they need to do:
- Customers: book a service, see their bookings, get reminders.
- Staff: see their jobs for the day, mark them done.
- Admin or owner: manage availability, prices and bookings, see reports.
Mention who is not a user, too. If staff will keep using a shared tablet rather than their own phones, say so.
3. How things work today
Describe the current process honestly, including the workarounds: the spreadsheet, the WhatsApp group, the paper form. Attach examples if you can. The current process often contains business rules that nobody thinks to mention, such as "we never book the same team in two different areas on the same morning", and these rules are exactly what the developer needs to know.
4. The key flows
Pick the three to five most important journeys and describe them step by step from the user's point of view:
- Customer opens the app, chooses a service and the size of the home.
- Sees the price and the available slots for the next two weeks.
- Picks a slot, adds the address and notes, confirms.
- Gets a confirmation, and a reminder the day before.
You do not need to design screens. Steps in plain words are enough. The developer will turn them into wireframes.
5. Must-have versus later
Split your wishes into two lists:
- Must have for launch: without these, the product does not solve the problem.
- Later: valuable, but the launch can happen without them.
Be strict. Most projects launch faster and better with a short must-have list. I go deeper into this in scoping your MVP.
6. Platforms and languages
- Mobile app, website, web app, or a combination? If you are not sure, describe the users and tasks and ask. See website or web app.
- iOS, Android or both?
- Which languages? English, Arabic, French? Arabic needs right-to-left layouts, so say it upfront.
7. Content and data
Who will provide texts, service lists, prices, product data and photos, in every language? Is there existing data to import, such as a customer list or a product catalogue? Content that arrives late is one of the most common causes of delay.
8. Integrations
List the outside services involved: payment methods, SMS or WhatsApp notifications, maps, email, accounting software, an existing system. For each, say whether you already have an account. For payment specifics in Lebanon, see accepting payments in your app or website.
9. Design references
Share two or three apps or sites you like, and say what you like about each: the simplicity of the booking flow, the colours, the way the menu works. Share your logo and brand guidelines if you have them. Also share what you dislike; it is just as useful.
10. Constraints
- Deadlines, and why they exist (a season, an event, a contract).
- Budget range. You do not have to share it, but a range helps the developer propose what fits rather than the ideal version.
- Technical constraints: an existing system, a required hosting location, a policy from your organization.
11. Ownership and after launch
State that you will own the code, accounts and servers. Mention whether you expect the developer to maintain the product after launch and how quickly issues need fixing. See app maintenance after launch.
12. Out of scope
Write down what you are deliberately not building. "No in-app payments in the first version." "No staff app; staff use the web admin." This avoids misunderstandings later and is often the most valuable part of a brief.
A template you can copy
Project name:
The problem (2 sentences):
Users and what each needs to do:
How it works today:
Key flows (3 to 5, step by step):
Must have for launch:
Later:
Platforms (iOS / Android / web) and languages:
Content and data (who provides what):
Integrations:
Design references (liked / disliked, and why):
Deadline and why:
Budget range (optional):
Ownership and maintenance expectations:
Out of scope:
Contact person and availability for questions:What happens next
With a brief like this, a good developer can come back with clarifying questions, a proposed scope, a technical approach and a realistic estimate. Expect questions. A developer who asks none probably has not thought about your problem in enough detail.
Some developers offer a short paid discovery phase to turn your brief into a full specification and plan. For larger projects that is worth it, because it gives you a document you can use with anyone.
How long should it be?
Long enough to answer the questions above, and no longer. Two to four pages is typical for a business app or website. Bullet points are fine. Screenshots of your current spreadsheet or forms are often more useful than paragraphs. If you find yourself writing pages about a feature that is on the "later" list, stop and move on; that detail can wait until it is actually being built.
Common mistakes in briefs
- Listing features without the problem.
- Copying a competitor's feature list wholesale.
- Leaving out the admin side.
- Forgetting languages, especially Arabic.
- No owner on your side who can answer questions.
If you have a project in mind, put together what you can using the template and get in touch. It does not need to be perfect; it just needs to be honest about what you know and what you do not. You can also see my work for examples of what this process produces.