How to Read a Development Proposal

A proposal is an argument, not a price list

Most proposals are read once, skimmed for the number, and compared against other proposals by a client trying to make the same decision as fast as possible. That process produces a bad outcome for everybody. You end up comparing documents written to different standards, and the cheapest one usually wins because it is the least detailed.

A proposal is really three things stacked on top of each other: a description of what they think you want, a plan for how they would build it, and a contract that governs everything else. The price is the least interesting part. What you need to read is whether the first two are any good, because a well-reasoned plan delivered late is recoverable, whereas a cheap plan built on the wrong understanding of your business is not.

The habit worth building is to read a proposal twice. First pass for the shape: what have they understood, what have they proposed, what have they left out. Second pass for the parts you cannot check, which are the parts that determine whether the project works.

Read the restatement before anything else

Every serious proposal opens by describing your problem in its own words. That paragraph is the most valuable part of the document and the part most clients skip, because it sounds like filler.

It is not filler. It is a comprehension test. If their restatement mentions things you never said, they have filled the gaps with assumptions from previous projects, and those assumptions will be in the code. If it is vague where your business is specific, you are paying a developer to discover your own requirements at your hourly rate.

If the restatement is thin, ask for a rewrite before asking for a revised price. A few firms will do it as part of the process. It costs them an hour and it frequently saves a month.

Read the scope for what is missing

Scope sections are almost always written as a list of things that will be built. The valuable reading is the opposite direction: work backwards from launch day and list everything that has to be true, then check what is absent.

• Data. Who cleans it? Who maps the old fields to the new ones? What happens to records you cannot map? Is there a migration rehearsal, and who signs it off?
• Content. Who writes it, who edits it, who publishes it, and on which day? A content-dependent launch date is a launch date at risk.
• Integrations. Each external system is a dependency with an owner on the other side. If a proposal lists four integrations and names no counterparties, it has not talked to anybody yet.
• Roles and permissions. Usually under-specified, always expensive to add late, because they affect every screen, every query and every test.
• Reporting. Analytics, exports, and audit logs are frequently assumed rather than specified. They are the features users ask for in month three.
• Staging and environments. One environment is not enough to build anything safely. A reviewable test environment changes how the work is done.

There is a version of this exercise on our quality assurance page that is aimed at teams hiring testers rather than clients, but the underlying point is the same: the defects you find in month nine are defects somebody decided not to look for in month one.

Read the plan for who does what, and when

A list of phases with dates attached tells you very little. What tells you something is the structure underneath: who is accountable, what has to be finished before the next thing starts, and where a parallel track could quietly become a blocker.

• Is there a named delivery lead or project manager, or is this the account manager’s job as well? Both are viable; nobody knowing is not.
• Is there a design phase with a client review gate, or does design happen inline and get approved by whoever saw it first?
• Is testing a phase at the end, or continuous throughout? End-of-project testing compresses three months of feedback into three weeks and makes a difficult conversation inevitable.
• Is there anything in the plan that assumes two people working in parallel on the same part of the system? Sequential work that is scheduled as parallel is the single most common reason a timeline slips.
• Are the dependencies between phases written down, or only the phase names?

SmartEdge IT Solutions publishes the stages we work through on our process page partly because it makes conversations faster. When both sides know what the next gate is, you spend the meeting on the actual problem rather than on establishing what happens next.

Read the commercials closely, then read them again

The pricing section is where a proposal quietly commits you to something. Four patterns are worth looking for.

Hourly with a range. A wide range is honest but leaves you exposed. Ask what has to happen for the work to land at the bottom of it, and treat the top as the number you budget for.

Fixed price on an undefined scope. This transfers risk to the supplier, and they will price it accordingly, or they will underprice it deliberately in the hope of winning change requests later. Ask what happens to the price if a requirement turns out to be harder than expected. There is a correct answer, and it is that you discuss it rather than either side simply asserting a position.

Milestones without acceptance criteria. “Design complete” is meaningless. “Design complete and approved by your product owner against a written list of screens” is enforceable. Ask for acceptance criteria on every milestone.

Exclusions written as broad categories. “Third-party costs excluded” is fine. “Changes to requirements excluded” is a warning sign, because requirements will change and you did not cause it.

On payment structure, smaller milestones are generally better for the client and worse for the supplier’s cash flow, which is why some firms resist them. Ten per cent of something you cannot verify is a worse position than a smaller amount against a completed, working increment. See how this works in practice on our ERP development page, where the phases are tied to business outcomes rather than to months.

The parts of the proposal that are not about delivery

Every proposal contains a section that exists to reduce the supplier’s risk, and reading it is a good way to predict where the project will get difficult.

• Liability caps tell you what happens if the delivered system causes loss. Check whether the cap excludes data loss specifically, because that is a common carve-out.
• Payment terms tell you who is funding the project and for how long.
• Client-dependency clauses tell you which delays will be reclassified as your fault. These are usually accurate and worth reading properly, because they define the project’s real schedule risk.
• Intellectual property assignment tells you who can reuse what they built for you. For bespoke work this should be clean and unconditional.
• Termination clauses tell you how you get your code back. Look for a handover period expressed in days.

We hold the same positions ourselves, which is why the terms and conditions on this site are written to be read rather than to be signed unread.

Signals in the writing itself

Proposals are often drafted by someone who did not attend the discovery call, from notes written by someone who did not build anything. The seams are visible.

• Stock imagery in the diagrams. Wireframes full of placeholder dashboards and made-up metrics mean the designer did not look at your data.
• Feature names but no user stories. “Advanced reporting module” tells you nothing about what it produces.
• Risk sections that only list technology risk. Where are the schedule risks, the dependency risks, the adoption risks?
• No mention of anything not working. A proposal that describes no trade-off has been written by someone selling rather than planning.
• Three-page timeline with a launch date on page one. Dates anchored before discovery are commitments made before understanding.

None of this is a reason to reject a firm on its own. It is a reason to ask a question and watch the answer.

It also helps to remember that a proposal is partly a sales document and a partly a technical one, and those two jobs pull in opposite directions. The technical half wants to describe uncertainty in detail, because that is how risk gets managed. The sales half wants the document to be short and the price to be the memorable thing. The proposals you most want are the ones where both halves are present, which usually means the firm was willing to be honest about the difficult parts in order to be trusted on the rest.

One more practical test: take a random page from the proposal and hand it to someone in your organisation who will not otherwise be involved in the project. If they can say what is being proposed and what happens next without help, the document is doing its job. If they hand it back asking what a term means, the proposal has been written for the supplier’s client and not for yours. That is common, and it is fixable: SmartEdge IT Solutions will rewrite a proposal into plain language when a client says the first version did not make sense to the people who have to approve it.

What to do before you sign

Send one short list of queries back to the supplier and expect it to be handled properly. A firm that takes two weeks and returns a defensive answer to three specific questions about assumptions has told you something useful.

Then ask for the awkward part: what is your biggest concern about this project, what would you do differently, and what would make you recommend not proceeding. Firms do not enjoy this question, which is why the answer is informative.

Finally, compare proposals on the template we use internally when we are on the buying side. Rewrite each scope into your own words, mark the gaps yourself, and cost the gaps. Two proposals that both say “CRM integration” can differ by four figures once you have written down what each actually means, and that CRM integration work is usually the largest single line in a business system budget.

You are not trying to find a proposal that is perfect. You are trying to find one where the assumptions are visible, the missing work is named, and the person who wrote it would be uncomfortable if you did not read it.

If you are short of either time or expertise to do that reading properly, say so when you ask for help. A firm that will walk you through their own proposal line by line is doing something rare and useful. One that will not is telling you how it expects to be bought, which for many clients is entirely reasonable.