How to write a software project brief before asking for a quote

A useful project brief describes the problem and the decisions a delivery team needs to make. You do not need to choose every framework before speaking to an engineer. You do need to explain who will use the software, what they need to achieve and how you will decide that the first release works.

Start with one user and one complete workflow

Describe who starts the workflow, what information they have, what happens next and what a successful outcome looks like. For an appointment system, an illustrative workflow is: a customer chooses a service, sees available times, books a slot and receives confirmation. Then describe exceptions such as cancellation, an unavailable slot or a failed confirmation. This is an example, not a customer case study.

Separate the first release from later ideas

• Must have: the smallest set of workflows that makes the release useful.
• Later: useful additions that can wait, such as another payment provider or an advanced reporting dashboard.
• Out of scope: work explicitly excluded from the estimate, such as writing all marketing copy or migrating an undocumented legacy database.
• Dependencies: decisions, accounts, content or access your team needs to provide.

Describe the systems and data involved

List existing applications, integrations and data sources. For each integration, identify whether documentation, a test environment and an account owner exist. Describe data types and access roles without putting passwords, access tokens or customer records into the brief. A data migration needs its own sample structure, quality checks and rollback plan.

Make acceptance criteria observable

Replace “the site should be fast” with a page, device, connection profile and agreed measurement. Replace “secure login” with the required sign-in methods, roles and account-recovery flows, then agree the security review. For each main workflow, write a condition a reviewer can actually test. If a number is still unknown, mark it as a decision to resolve rather than guessing.

Explain timing, budget and ownership

• State whether a date is a preference or tied to an external launch. Identify the minimum scope needed by that date.
• Give a budget range if you have one and ask which scope is feasible within it.
• Name the person who approves scope and the people who will review work.
• Agree who owns the source repository, cloud accounts, domains and ongoing service subscriptions.
• Ask what documentation, training, support window and handover are included.

Compare proposals against the same questions

Ask each provider to list assumptions, exclusions, delivery stages, acceptance criteria and ongoing costs. Check how changes are estimated and approved. If the scope is still uncertain, request a bounded discovery phase with explicit deliverables rather than treating an early estimate as a fixed commitment.

A brief you can copy

• Problem and primary user:
• Current workflow and its main difficulty:
• First-release workflow and success condition:
• Must-have features / later features / exclusions:
• Integrations, data sources and migration needs:
• Access roles and review requirements:
• Target date, budget range and dependencies:
• Decision-maker, review cadence and handover expectations:

Bring this brief to your first scoping conversation. Leave unknowns visible: a useful proposal should explain how those questions will be resolved, not conceal them behind a precise-looking price.