Start with the people and what they need to get done

Name each group that will use the software: customers, staff, managers, suppliers. Give a rough idea of how many there are. Then list the main things each group needs to do, in plain sentences.

A customer books a time slot and pays online. Staff see the day's bookings and mark each one complete. A manager exports the month's sales for the accountant. Three sentences like these tell a developer more than a feature list such as "booking module, admin panel, reports", because they show who does what and in which order.

Describe how the work gets done today

Explain the current process, even if it runs on spreadsheets, email and paper. Say which steps take the longest and where mistakes happen. This shows the developer what the software has to beat.

List the systems the new software has to work with, such as an accounting package, a payment provider, a CRM or an existing website. Mention any data that has to move across, roughly how much there is and what form it is in. Connections and data moves are a common source of surprise costs, and naming them early gets them priced.

Separate what the first version must do from what can wait

Mark each item as essential for launch or wanted later. A quote for everything at once is large and uncertain. A first version is smaller, reaches its users sooner, and lets the later stages be priced with real feedback.

Share your budget range and your dates

The same goal can often be met by configuring an existing product, by a focused build or by a larger platform. A budget range tells the developer which of these to propose. Without one they have to guess, and the proposals you receive cannot be compared.

Give any fixed dates and the reason behind them: a launch event, a contract that starts, a regulation that takes effect. A developer can then say what fits in the time available.

Mention the constraints a developer cannot guess

Some facts change the price considerably and are easy to leave out:

  • Whether the software handles personal, medical or payment data.
  • Rules that apply to your industry or your customers' countries.
  • Where it will be used: office computers, phones on site, places with a poor connection.
  • The languages it needs to support.
  • Accessibility requirements.
  • Who will look after it once it is live.

What you can leave out

There is no need to choose the technology, design the database or draw every screen. Those decisions belong in the developer's proposal, and a good one explains them in plain terms. A rough sketch, or screenshots of software you like using, are welcome and take minutes to gather.

A good reply asks questions before it names a price

A developer who has read the brief properly will come back with questions. A price that arrives without any, for a project of any size, is a guess.

The proposal that follows should state what is included and what is excluded, the price, the timing, how changes are handled, who owns the code and what happens after launch. Compare proposals on those points. The lowest figure often covers the least.

The whole brief fits in one paragraph

A complete brief says who uses the software and what they need to do, how the work gets done today and which systems are involved, what the first version must include, your budget range and dates, and the constraints a developer would not guess.

Our project form has room for all of it. Send it, and we reply in writing with questions or a proposal.