Proposals
A proposal is a prediction about work nobody has done yet. What matters is not the confidence of the prediction but whether it exposes its own reasoning: what was assumed, what was excluded, and what happens when an assumption turns out wrong.
Every estimate rests on assumptions. Stated ones can be checked and challenged. Unstated ones become change requests.
Items you can recognise, with days against each. A single figure for 'development' cannot be evaluated, only accepted or refused.
The person who wrote the proposal is often not the person who writes the code. Ask for the name and the experience of whoever will actually be assigned.
Read these before you look at the total. They determine whether the total means anything.
A large spread between quotes almost never means one supplier is dishonest. It usually means they scoped different amounts of work, because your brief left room to.
The cheap one may have assumed your existing system has a working API, that you will supply the designs, that data migration is your problem, and that testing means the developer clicking through it once. The expensive one may have assumed the opposite of each.
Neither is wrong until you compare them against the same assumption list. Ask both suppliers to price the same explicit set, and the gap usually collapses to something reasonable.
A proposal that makes no demands on you is a warning sign. Real projects need decisions, content, access and review time from the client, and a supplier who has thought about the schedule knows this.
Look for stated dependencies on your side, with dates. Their absence usually means the timeline is decorative, and that when it slips the reason offered will be that you were slow.
Fixed price moves risk to the supplier, and the supplier prices that risk. Expect a padding of a third or more, and expect firm resistance to anything not written down.
Time and materials keeps the risk with you and costs less when the work is well understood, but it requires you to pay attention. For most small projects, a fixed price for a well-defined first phase followed by time and materials for the rest is the arrangement that goes wrong least often.
Not necessarily, but find out what it excludes. Usually the difference is testing, data migration, or the assumption that you supply designs and content.
Detail helps only if it is specific to you. Twenty pages of generic methodology is not more informative than one page of assumptions about your actual system.
