Most project briefs we see are one line long. “We need an app like Zomato.” Or “Make us a website, modern look, around 10 pages.” Then the person is surprised when three developers send three quotes, and the cheapest and most expensive differ by a factor of five.
That isn’t the developers being unreasonable. A one-line brief leaves out everything that decides the price and the timeline, so each developer fills in the gaps with their own guesses. The fix isn’t a 40-page document. It’s a short brief that answers the questions a developer would otherwise have to ask you in five separate calls.
Start with the problem, not the feature list
Before you describe screens or buttons, write two or three sentences about what’s going wrong today and what should be different afterwards. “Our team takes orders on WhatsApp and copies them into Excel, and we make mistakes every week” tells a developer far more than “we need an order management system.”
Why does this matter? Because a good developer will sometimes suggest something simpler than what you asked for. They can only do that if they know the real problem.
Say who will use it
List the types of users and what each one needs to do. Customers, staff, an admin, maybe a delivery person. Even a few lines per group is enough.
- How many people will use it, roughly? Fifty customers a month and fifty thousand are very different projects.
- Are they comfortable with technology, or do they need things as simple as possible?
- What language do they speak? If you need Gujarati or Hindi along with English, say so now. It affects design and testing more than people expect.
- Will they mostly be on phones? In India, the answer is usually yes.
Split features into three piles
This is the single most useful thing you can do. Write your features, then sort them.
- Must have for launch: the app is useless without these.
- Nice to have: add them if time and budget allow.
- Later: good ideas, but not for version one.
Without this split, every feature looks equally important, and the developer prices all of it. With it, you can launch something useful sooner and add the rest once real users show you what they actually want.
Show examples
Send two or three websites or apps you like, and say what you like about each. “I like how simple their checkout is” is helpful. “Make it look like this” with no explanation isn’t, because the developer doesn’t know whether you mean the colours, the layout or the whole behaviour. If there’s something you definitely don’t want, mention that too.
List what it has to connect to
Integrations are where hidden work lives. A payment gateway, WhatsApp messages, SMS or email notifications, an accounting tool, Google Maps, an existing database. Each one adds time, and some have their own approval process before they work.
If you already have a website, an app or a database, tell the developer. Building on top of something that exists is a different job from starting fresh, and sometimes the old system has problems you should both know about before you start.
Be honest about content and data
Who is providing the text, product photos, logo and prices? Is your existing data clean, or are there ten versions of the same customer in your spreadsheet? Many projects run late for a boring reason: the developer finished, and the content never arrived. Agree up front who supplies what, and by when.
Give a budget range and a real deadline
A lot of people avoid sharing a budget because they think it’ll push the price up. In practice, a range helps the developer tell you what’s realistic, and sometimes suggest a cheaper approach that still solves your problem. If you really don’t know, say so, and ask for options at two or three price levels.
For deadlines, explain why. “We need it before Diwali because that’s our busiest sale” lets the team plan around the real constraint. “ASAP” doesn’t.
Name the decision maker
Who approves designs and says “yes, this is done”? One person is ideal. Projects with five people giving separate feedback tend to go in circles, and every round of changes costs time. If several people need a say, collect their comments yourself and send one combined list.
Describe what “finished” looks like
Add a few lines on how you’ll know the project worked. For example: a customer can place an order and pay in under two minutes, staff can see all new orders on one screen, and the owner gets a daily summary on WhatsApp. These become simple checks at the end, so nobody argues about whether it’s done.
A short template you can copy
Put this at the top of an email or document and fill in each line.
- About us: what the business does, in two lines.
- The problem: what’s going wrong now.
- The goal: what should be different after launch.
- Users: who they are, how many, which languages, which devices.
- Features: must have, nice to have, later.
- Examples: 2-3 links, with what you like about each.
- Integrations: payments, messaging, other tools.
- Existing systems: website, app, database, if any.
- Content: who provides it, and when.
- Budget and timeline: a range, and the reason for the date.
- Decision maker: one name.
- Success looks like: 3-4 simple checks.
Mistakes that cost you later
The first is describing a solution when you should be describing the problem. “Add a chatbot” might not be what you need, even if it feels like it. The second is leaving things out because they seem obvious to you, like a login for staff or an admin screen. They’re obvious to you, and not to someone starting from zero. The third is changing the brief halfway through without telling anyone the price or date will move. Change is fine, just have the conversation when it happens.
Conclusion
A good brief doesn’t need clever wording or technical terms. It needs to say what’s going wrong, who it’s for, what matters most, and what finished looks like. An hour spent on that saves you weeks of confusion and, usually, a fair amount of money.
At Next Generation Technologies, we’re happy to help you shape a rough idea into a clear brief before any work begins. Not sure what to write, or have a half-finished brief? Contact us and let’s talk it through.
