Read a proposal for what it does not say. Almost everything that goes wrong later is not a statement in the document that turned out to be false — it is a subject the document never raised, which therefore became somebody's problem after the money was spent. Price and timeline are the two things every reader checks and the two things least likely to be the source of the damage.
Work through it in this order: what is excluded, who ends up owning what, what happens if the relationship ends, what recurs monthly, and only then whether the timeline is plausible for the scope. Anything the proposal leaves silent is not a small omission to tidy up in the contract later — it is the vendor's answer to a question you have not asked yet, and you will get their answer by default.
Two proposals for the same investor portal: one at 62,000 and one at 41,000. The cheaper one has no back-office section, does not name who holds the cloud account, and lists "deployment" as a single line. It is not cheaper. It is a different, smaller job, and the difference will be quoted as change requests once you are committed to it.
Every proposal has three categories: included, explicitly excluded, and unmentioned. The first is marketing, the second is honesty, and the third is where the change requests come from. If the excluded list is empty, that is a finding in itself — it means nothing has been scoped out, which is never true.
Source code, repository, cloud infrastructure, backups, and when intellectual property assigns. Five questions. A proposal that answers none of them is not neutral about ownership; it has simply left the answer to whoever holds the accounts.
What is handed over, in what form, and on what trigger. If the document does not describe leaving, you are relying on goodwill at exactly the moment goodwill has run out.
Hosting, licences, third-party services, per-transaction fees, and support after delivery. A build price is a number you pay once; the recurring total is the number you live with, and it is often the one that decides whether the product is viable.
Distinguish "we will support it" from a stated scope, hours, response expectation and price. The first is a sentiment. The second is something you can hold somebody to.
Count the integrations. Each external system — identity, payments, payouts, banking, reporting — brings its own onboarding, its own sandbox and its own approval. A timeline that does not visibly account for them is measuring development, not delivery.
A proposal that lists its assumptions and its risks is easier to trust than one that reads as if nothing could go wrong. The declared assumptions are also the fastest route to the questions worth asking.
A call answers the questions you brought. Anything you did not write down gets answered by whatever the vendor wanted to talk about, and you will remember the conversation as having gone well.
