A proposal should answer twenty-five questions. Five of them are critical, in the sense that leaving them blank can undo everything the other twenty get right: who owns the source, who owns the repository, who owns the infrastructure, when intellectual property assigns, and what happens on exit. A beautiful proposal that is silent on those five is a worse purchase than a plain one that answers them.
Use the list below as a scoring sheet rather than a wish list. Mark each item answered, partly answered, or absent. The absent column is the real output: it is both your question list for the vendor and, if two vendors are involved, the only basis on which their proposals can be compared at all.
A founder asked three vendors to add "the missing items" from this list to their quotes. Two came back with a revised price roughly 20% higher and a much longer document. The third said the questions were not relevant at this stage and did not revise. That answer was the most useful information in the whole procurement.
An itemised list of what is built, an explicit list of what is not, the architecture in enough detail to be argued with, the technology stack, and who is actually on the team. "Backend, app and admin panel" is a category, not a scope.
Source ownership, repository ownership and infrastructure ownership, each answered with a party rather than a mood. "Client", "vendor", "shared" and "escrow" are all workable arrangements; "not stated" is the only one that is not.
When rights transfer: on payment, on completion, or not at all. And what exactly transfers — the client-specific implementation is not the same thing as every component the vendor reused to build it.
What is handed over, in what format, on what notice, and at what cost. Code, database schema and data, deployment configuration, documentation and tests.
Who holds the backups, where, how often, and whether you can obtain a restorable copy of your own data without asking permission.
Recurring costs, third-party costs named individually, and a payment schedule tied to something observable rather than to elapsed weeks.
Support scope and duration, response expectations if any are offered, and a division of security responsibilities between you and the vendor. Vague security language is worth less than a short honest list.
What the vendor is depending on you to provide, what they have assumed to produce this price, and what they think could go wrong. All three are signs of a proposal written by somebody who has delivered before.
How you will know it is finished. Acceptance criteria, what testing is included, and what documentation you receive — the three things most often assumed and least often written down.
