Requirements
Templates fail when they are long enough to feel thorough and generic enough to be filled in without thinking. This one is deliberately short: every section exists because a supplier cannot price the work without it.
Problem, users, environment, constraints, what you want back, how you decide. A paragraph each is enough to start.
Requirements nobody intends to check teach suppliers to treat the whole document as decorative.
If a colleague who does not know the work cannot say what you want after one read, no supplier will either.
What happens today, what it costs in time or money or lost customers, and what should be true when the work is finished. No technology in this section.
Suppliers use this to decide whether to bid at all, and to judge whether the approach they have in mind actually solves your problem or just the part of it you described most vividly.
Each kind of user, roughly how many there are, and what each needs to do. Distinguish people inside your organisation from customers, and note anyone with different permissions.
This drives more of the price than anything except payments. Two user types with different views is a different piece of software from one type with a single view.
What already exists, what must keep working, and what data has to move between systems. Name the products by name, and say whether each has an API and whether anyone has used it.
Integrations with undocumented or legacy systems are where estimates go wrong most often. Saying so up front gets you an honest price instead of a cheerful one.
Budget range, the deadline and the real reason behind it, regulatory obligations, and who has to maintain the result afterwards.
The maintenance question is quietly important. A solution built in a stack nobody in your organisation can touch is a different proposition from one your existing team can extend, even if both work equally well on day one.
State the format: an itemised breakdown, days per item, a range rather than a single figure, the assumptions the price depends on, and the name of the person who would do the work.
Ask explicitly what you own at the end. Code, accounts, design files, and when ownership transfers. Leaving this to the contract stage is how it ends up conditional on final payment.
Criteria with weightings, the questions deadline, and the date you will choose. If price is not the main factor, say what is.
Publishing this changes the proposals you get. Suppliers write to the criteria they can see, and you get answers that are comparable rather than a pile of documents in six different shapes.
Yes, but ask for the assumption list alongside the fixed price. A fixed price without stated assumptions is a fixed price until the first surprise.
That is the good outcome. A supplier who asks nothing before quoting has either done this exact project before or is not thinking about yours.
