What to look for in a software proposal

A proposal is a sales document, so it is tempting to read it as one: skim the scope, find the total, compare. Done that way, three proposals collapse into three numbers, and the decision gets made on the axis where the differences mean least.

Read differently, the same document tells you something far more useful. It is the only sample of the supplier’s actual work you get before you hire them. Not the portfolio — the thinking. A proposal is somebody’s first attempt at understanding your problem, written down where you can check it.

Six things worth reading

1. Does it restate your problem, or list their features?

The first page should describe your situation back to you, in enough detail that you can tell whether they were listening. If it opens with their methodology, their stack, or their years in business, they have written the same first page for everyone. A proposal that gets one detail of your business subtly wrong is more encouraging than one that says nothing specific enough to be wrong.

2. What is explicitly out of scope?

Every proposal lists what is included. The good ones also list what is not, by name. Content migration, training, the integration with the accounting system, the second language — these are the things that turn into change requests, and a supplier who has already thought about them is telling you they have done this before. An absent out-of-scope section does not mean everything is included. It means the boundary is undecided, and it will be decided later, under pressure, in their favour.

3. What happens after launch, and is it priced?

Ask specifically. If there is no line for maintenance, updates, or support, there are two possibilities: they intend to charge for it later, or they have not thought about it. Neither is disqualifying, both are worth knowing now. A figure for the first year of running costs, even a rough one, separates the suppliers who have watched a system age from the ones who have only launched things.

4. Who actually does the work?

The people in the meeting are not always the people who write the code. This is not sinister — it is how agencies staff projects — but you should know whether you are buying the senior person’s judgement or their supervision. Ask who is assigned, at what percentage, and what happens if they leave mid-project.

5. What do you own at the end?

Code, design files, content, the domain, the hosting account, the analytics property. The answer should be “you do”, and it should be written down. Where it is not, find out why. A supplier who retains the hosting account is not necessarily acting badly, but you should know that leaving them means a migration rather than a handover.

6. What are the assumptions, and what happens if one is wrong?

Any honest estimate rests on assumptions: content arrives by a date, one round of revisions, the API works as documented. Listed assumptions are a sign of someone who has been burned and learned. Unlisted ones still exist — they are simply not yours to see until they fail.

Two things that should worry you

A total with no breakdown. Not because the number is wrong, but because you cannot negotiate scope against a single figure. When the budget is tight, a broken-down proposal lets you drop the thing you need least. An undivided one leaves you choosing between all of it and none of it.

A timeline with no dependency on you. Every real project waits on the client for something: content, approvals, access, a decision. A plan that shows only the supplier’s work has quietly moved all the schedule risk onto whichever side is less able to argue about it later.

The question that sorts them fastest

Ask each supplier: what is the riskiest part of this project, and what would you do about it?

The answers separate immediately. Some will say there is no real risk, which means they have not looked. Some will name a risk that is yours to carry — content, approvals, an unclear decision-maker — which is fair, and worth hearing. And some will name a risk in their own part of the work and describe how they would find out about it early.

That last group is the one worth paying.