How To Write A Project Brief That Produces A Realistic Quote

Begin with the problem you are solving, not your preferred technology. Who will use the system, how many times a day, and what does the process look like without it? A vendor who grasps the purpose often proposes an alternative that costs less; someone handed only a list of screens can only price the list as written.



Define what is included as user stories or scenarios: a walk through each important path. Equally important, state explicitly what is out of scope. A written out-of-scope list prevents more argument at delivery time than almost anything else in the document. Also mark which parts are firm and which may still change — honest teams price those differently, and pretending everything is fixed only hurts you.



List the constraints. This means existing systems the software has to talk to, existing databases and their quality, regulatory obligations, user volumes, target platforms and any technology you are committed to. If there is a hard date, say why: an experienced team can often rearrange the plan to protect it, but not if the date is a secret.



Say what completion means cost per hour for outsourced software development each item. Testable acceptance criteria do not need any formal notation: a plain-language note describing what must be true when the feature works is sufficient. This single habit shortens the review at the end considerably and closes off the usual argument at handover.



Finally, state what you want in house team vs outsourcing costs the response. Request a task-level breakdown, the assumptions behind each number, whatever the team considers risky and an optimistic and a pessimistic figure. Read a wide range as a signal about the brief: it usually points to where your description is thin. Then tighten that section and request a revised number — the revised figure tends to be much more reliable.