What a fixed-scope proposal should contain

A proposal is not a price on a page; it is a definition of the deal, and the price is only meaningful once the definition is clear. A good proposal protects you by making it obvious what you are buying and, just as importantly, what you are not. Here is what a real one contains, so you can tell a solid proposal from a hopeful one.

The scope, and the exclusions that matter more

The heart of a proposal is a plain description of what will be built, specific enough that both sides picture the same thing. But the part that protects you most is often the exclusions: the explicit list of what is not included. A proposal that only says what it covers leaves every unmentioned thing open to argument later. A proposal that also says, in writing, what it deliberately leaves out, whether that is a mobile app, a particular integration, or ongoing support, removes the room for a later dispute. When a proposal is confident enough to tell you what it will not do, that is usually a sign it has thought carefully about what it will.

The assumptions the price depends on

Every fixed price rests on assumptions, and an honest proposal states them. The most important is the assumed state of your prototype: whether it is treated as a sound foundation to build on or as something that needs rework first. Others include how much data will be migrated, which services you will provide access to, and how quickly you will answer questions during the build. These assumptions are not fine print; they are the load-bearing conditions under which the number holds. If an assumption turns out to be wrong, a good proposal says how that is handled, so a surprise about your foundation becomes a known adjustment rather than a fight. A proposal with no stated assumptions is not simpler; it is just hiding where the risk lives.

What you actually receive, and how you know it is done

A proposal should list the deliverables in concrete terms: the working application, the code in a repository you own, the accounts and services in your name, any documentation, and the handover itself. Vague promises like a finished product are not deliverables; a named list is. Alongside that, it should define acceptance criteria, the agreed test for when the work is complete, so done is a fact both sides can check rather than an opinion someone can dispute. Without acceptance criteria, the end of a project can drift indefinitely, with each side holding a different picture of finished. A clear finish line, written down before work starts, is one of the most valuable things a proposal can give you.

Change, ownership and the exit

Two final things separate a real proposal from a hopeful one. First, how change is handled: since you will inevitably want something beyond the original scope, the proposal should say how a change request is priced and agreed, so new requests are a calm, known process rather than an argument or an open cheque. Second, ownership and exit: the proposal should state plainly that you own the code, the data and the accounts at the end, and that you can walk away with everything, because software you cannot take with you is software you are renting. A proposal that leaves ownership unstated, or makes leaving difficult, is telling you something important. The best proposals make the exit as clear as the entrance.