Before you hire a developer, write this one-page brief

Almost every project that runs late or over budget has the same origin story: the brief was a list of features. “We need a dashboard, a login, WhatsApp integration and reports.” It sounds specific, but it says nothing about the problem — so the developer guesses, quotes for the guess, and builds the guess.

I start every project with a one-page brief. It takes about an hour to write, and it is the single cheapest way to protect your budget. Here is the template, with the reasoning behind each question.

1. What problem are we solving?

Write it as a sentence about the business, not the software. “Our sales team loses track of follow-ups after the first call” is a problem. “We need a CRM” is a solution someone has already chosen.

If you can, attach a number: hours lost per week, leads that go cold, invoices that go out late. A number turns “nice to have” into a decision you can measure later.

2. Who feels it, and how often?

List the people who will use the thing — by role, not by name — and how often they hit the problem. A tool used by three people once a month is a very different project from one used by forty people every hour.

This is also where you find the real requirements. The person who chases documents every morning knows exactly which step is painful; the person signing the cheque often doesn’t.

3. How is it handled today?

Describe the current workflow, including the messy parts: the shared spreadsheet, the WhatsApp group, the copy-paste between two systems. Screenshots are gold here.

The current process tells a developer what data already exists, what must keep working on day one, and — very often — that half the problem can be solved with automation instead of new software.

4. What does “done” look like?

Pick one or two outcomes you can check after launch:

• “Every client gets a filing reminder seven days before the deadline, without anyone sending it manually.”
• “A new lead from the website is in the sheet and has a WhatsApp reply within five minutes.”
• “Month-end attendance reconciliation takes an hour instead of two days.”

These become the acceptance test. If the outcome happens, the project worked — regardless of how many features it has.

5. Constraints

The things that are not negotiable:

• Deadline — and why. A trade show date is real; “ASAP” usually isn’t.
• Systems it must connect to — Tally, Google Sheets, a payment gateway, an existing website.
• Who maintains it after launch, and how technical they are.
• Data rules — client documents, payment data, or anything regulated.

6. Budget range

Give a range, even a wide one. It is not a negotiation tactic; it tells the developer which version of the solution to propose. The same problem can often be solved with a ₹20k automation or a ₹2L custom app, and only the budget tells me which one you actually want.

What happens next

With these six answers, a developer can come back with something useful: a fixed scope, a set of user flows, a timeline in weekly milestones, and a price. Without them, every quote you receive is a guess dressed up as a number — and you can’t compare guesses.

The brief isn’t paperwork. It’s the first, cheapest version of the product.

If you want to try it, the brief form on my home page asks the short version of these questions — it takes two minutes, and I reply within a day. For a sense of how I run projects after the brief, see how I work.