A software proposal is a promise written by the party who gets paid for keeping it. That is not cynical, it is simply the situation, and it is why a proposal deserves the same reading you would give a lease.
This is the checklist we would hand a client who was about to read ours. Work down it with a pen.
Scope: what is in, and what is explicitly out
The most important section of any proposal is the one listing what is not included. If there is no such section, that is the first thing to ask for. Every item that is neither clearly in nor clearly out will become a conversation later, and later is when it is expensive.
- Is every screen or module named, or does one line cover a great deal?
- Does it say who provides content, images, product data and logos?
- Does it cover moving data over from the current system, and who cleans it?
- Does it include training, and for how many people?
Ownership: code, data and accounts
Look for a plain sentence saying who owns the source code when the final invoice is paid. Then look for the same about your data. Then check the accounts: the domain, the hosting, the store developer accounts, any third party service the system depends on. All of them should be in your company's name.
Assumptions: the quiet section that decides the price
Most proposals contain a list of assumptions, and most clients skip it. It is where the price actually comes from. Statements like a single round of feedback, or content supplied by a certain date, are the conditions the number depends on. If an assumption is unrealistic for your business, the price is not real either. Say so now.
Timeline: what depends on you
A schedule with no client dependencies in it is a schedule that has not been thought through. Real projects wait on approvals, on content, on somebody in your team being available. A good proposal names those and says what happens to the date when one slips.
Change requests: the mechanism, not the promise
Things will change. That is normal and not a problem when the mechanism is agreed in advance. You want to see how a change is requested, how it is priced, who signs it off, and what it does to the date, before the first one happens rather than during it.
Payment: what each stage is tied to
Stage payments should be tied to something you can verify, not to a calendar. Paying on a date rewards elapsed time. Paying on a demonstrable milestone rewards progress, and gives both sides an honest conversation at each step.
Hosting and running costs after launch
Look for the monthly and yearly figures, listed separately from the build. Hosting, domain, mailboxes, any third party service with its own fee, and the maintenance arrangement. A proposal without this section is describing half of what the project costs.
Support: the terms, in the proposal
What is covered after launch, for how long, and at what price after that. If support is a separate document, ask for it now rather than at handover, when your position is weaker.
Handover: what you receive on the last day
Write down what should exist when the project closes:
- The source code, in a repository you control
- Instructions for running and deploying it
- Every account and credential, in your name
- A copy of the data
- Whatever documentation the staff will actually use
Ask for it as a list in the proposal. A studio that has handed over before will produce it without hesitation.
The two questions to ask after reading
First: what is most likely to go wrong with this project, and what would we do about it? A truthful answer to that is worth more than any of the sections above, and an evasive one tells you plenty.
Second: what do you need from us to hit this date? A company that has delivered will have a precise list ready, because client delay is the most common cause of a late project and they have lived through it.
Rate the honesty of the answers, not the polish of the document. Anybody can format a proposal. Not everybody can tell you where it might fail.
Read ours the same way
We would rather spend an extra week on scope than discover the gap in month two, and we would rather lose a project on an honest limitation than win it on a vague sentence. If you have a proposal from anybody in front of you and want a second opinion on what it does not say, send it over. Our services and products pages describe what we would be proposing.