Write a software brief that a developer can estimate

Describe today’s workflow

Choose one real process and explain it from beginning to end. For example, an inquiry arrives, an employee records the request, a manager approves a quote and a customer receives the agreed details. Name the tools currently used and the points where people repeat work or lose information.

Use an anonymised example to make the problem concrete. Avoid sending passwords or real customer records in an initial inquiry. A description of the fields and a fictional sample usually provides enough context for the first discussion.

Name the users and their permissions

List who will use the system and what each person can do. An administrator may manage users, while an employee can create records and a supervisor can approve them. Explain whether customers need an account or only receive a document.

Also describe exceptions. Can an approved record be edited? Who can export information? What should happen when an employee leaves? These questions shape both the interface and the access controls, so they belong in the brief rather than being left until launch.

Define the smallest useful first release

Separate essential tasks from later improvements. A first release might let authorised staff create, find and update records with a clear status history. Automated messages, advanced reports and integrations can follow if the core workflow proves useful.

Describe success in observable terms. “Staff can find an inquiry by reference number and see its latest status” is testable. “Make the business fully automated” is too broad to estimate. Agree a small set of acceptance checks that the owner can run before approving delivery.

• User roles and allowed actions.
• Required fields, statuses and search behavior.
• Five essential tasks with an expected result for each.

Identify dependencies and operating conditions

List any existing website, spreadsheet, accounting tool or external service the software must connect to. State whether an authorised API or export is available, who owns the account and whether the service has fees. An integration is a dependency to verify, not a feature to promise before access is reviewed.

Explain where the software will be used: office computers, Android phones, a browser, unreliable connectivity or shared devices. If offline work is essential, say which tasks must work without a connection and how conflicts should be resolved when people reconnect.

Agree delivery and responsibility

Share a target date, budget range and the person who can answer questions. Ask for a proposal that separates discovery, development, review, deployment and ongoing support. Custom software is quoted after requirements and security review; a brochure website starting price is not a software estimate.

Confirm source ownership, backups, account handover, data retention and responsibility for updates. Include a way to report defects and distinguish fixes from new features. Before publication, test the agreed tasks with realistic sample data and confirm that access restrictions work for every role. A good brief becomes a shared checklist for that review.