How to brief a software project before you hire anyone

A useful brief is short. It tells a developer who uses the system, what job it replaces, and what “done” looks like in the first release. It does not need a technology stack, a colour palette, or a forty-page requirements document.

Most delayed projects start from the opposite document: a list of features copied from another product, with no sentence that says who will open the screen on a Tuesday morning. Write the Tuesday morning first.

• The person who will use it every week. Name the role: a store owner, a sales executive, a student, a warehouse clerk. “Users” is too vague to build from.
• The job they do today, and where it breaks. If the answer is WhatsApp plus a spreadsheet, say that. That is a real starting point.
• The one outcome the first version must produce. For a shop, that might be “I can see which items are below the reorder level.” For a services firm, “a visitor can send an enquiry that reaches a named person.”
• What is explicitly out of the first version. Payments, a second language, a mobile app, and a customer login are common additions. Leave them out unless the business cannot operate without them.

Priya runs a two-person spare-parts counter. She tracks stock in a notebook. She wants software so her brother can see the same stock when he is at the supplier. First version: item name, quantity on hand, reorder level, and a simple received-or-sold entry. Not in version one: an online store, GST invoicing, or barcode scanners. Those can follow once the stock numbers are trusted for a month.

That paragraph is enough to start a build. It names the people, the current record, the first outcome, and the boundary. A proposal can be checked against it. If a later quote adds a customer app, both sides can see that it was not in the brief.

You do not need to choose React, Next.js, or a database. JantaraX usually builds public sites in Next.js and React because that stack keeps pages fast and gives each service its own address for search, but that choice comes after the brief, not before it.

You do need to say whether the product is used on a phone in a shop, on a laptop in an office, or both. You also need to say who owns the domain name and the hosting login if a site already exists. A build that nobody can renew is not finished.

Read it aloud to someone who does the job. If they can point at a sentence and say “that is not how we work,” fix the sentence before you send it. A brief that describes the business as it actually runs will save more time than a brief that describes the software you wish you had.

Bring six lines to the first conversation: who uses it and how often, the current workaround, the first outcome, what is out of scope, who will answer questions during the build, and any date that is real rather than a preference. A shop opening or a filing deadline is real. “As soon as possible” is not.

The project brief tool on this site asks the same questions and gives you a page you can copy into an email. It does not replace the conversation. It stops the conversation starting from a blank page.