How to write your software requirements before you ask for quotes

Try sending three companies a message that says "I want a sales management system, how much?" You will get three figures that are multiples of each other. Not because one is overcharging and another is losing money, but because each imagined a different system and priced that. You are not comparing prices; you are comparing guesses.

A written document makes everyone price the same thing. It also protects you after signing: what is written in it goes into the contract, and what is not becomes a discussion about extra cost. Most disputes in software projects start with the sentence "we thought that was included".

There is a third benefit that matters just as much: writing forces you and your team to agree internally. Many projects stall because sales, accounting and management wanted three different systems and found out only after development had started.

The size follows the project. A profile website or a landing page needs one page: the goal, the list of pages, the languages, examples you like, the date. An app or a system needs a document of three to ten pages with the eight sections in the table above.

A formal request for proposals (RFP), with its forms, schedules and weighted evaluation criteria, is required in organisations governed by procurement rules and in large projects that several companies bid for. If you are not obliged to produce one, do not burden yourself: a short, clear document attracts better proposals than a long RFP that half the invited companies ignore.

If the project is large, or unclear even to you, there is a third option: a paid requirements study before you contract for the build, in which an analyst produces the list of screens and functions and a precise estimate. You pay a little to learn what you are about to buy, and you can take the result to any company.

Use one form for every function: "As a (who), I want to (what), so that (why)." For example: "As a sales supervisor, I want to see deals with no follow-up for seven days, so that I can step in before we lose them." One sentence has given the developer the screen, the rule and the purpose.

Then add underneath how you will know it has been done: "The list is sorted oldest first, with the rep’s name and the date of last contact." That line, called an acceptance criterion, is what you will test the work against at handover.

And put each function in one of three groups: must-have, without which the system cannot launch; important, which can wait a few weeks; and later. This grouping lets a company offer you a smaller, cheaper first version, and stops you paying from the start for features that may never be used.

Half the value of the document is on its last page: the format of the reply. Ask every company for the same things in the same order, set one deadline for receiving quotes and one channel for questions, and share the answers to questions with everyone.

A bad document can be worse than none, because it gives a false sense of clarity. These are the most common mistakes:

Go through your document against this list. If you can tick every item, it is ready to send.

If you send it to us at Fortune Code, we reply with a written quote within 24 hours that follows your numbering line by line, with a written delivery date, code and accounts in your name, and fast technical support after launch. If you do not have a document yet, we help you write one.