How to read a software development proposal (red flags)

Every failed software engagement we've been called in to rescue started with a proposal that, in retrospect, telegraphed exactly how the project would go wrong. The good news is that the tells are usually right there on the page. This is the checklist we walk clients through when they ask us to sanity-check a vendor proposal before signing — including proposals against us, which is a healthy conversation to have.

Pricing red flags

1. The "starting at" price

A proposal that opens with "starting at $75,000" and never lands on a real number is bait pricing. It exists to get the vendor into the room. The real number arrives after signature, in the form of scope-change orders. If a vendor cannot commit to a fixed number against a fixed scope, either the scope is genuinely unknown (in which case the right first engagement is a paid discovery, not a fixed-scope build) or the vendor is planning to price via amendments. Both cases need a hard conversation before signing.

2. Time and materials with no cap

T&M is a legitimate model. T&M with no ceiling and no burn-rate reporting is a mortgage. Every T&M contract should include a not-to-exceed number, weekly burn-rate reporting, and a defined re-forecast trigger.

3. Blended rates without a role mix

"Our blended rate is $135 per hour." Blended across what? A senior architect at $220 and three offshore junior engineers at $75 averages to $135. Two senior engineers at $170 and one lead at $200 also averages to $135. These are wildly different teams. Insist on named roles, named seniority, and named rates per role.

Scope and deliverable red flags

4. "Agile methodology" instead of scope

When the scope section of a proposal is a paragraph about "agile methodology, iterative delivery, and continuous collaboration," the vendor has told you they do not know what they are building. Agile is a way of building, not a substitute for knowing what you're building. Agile projects still need a scope — a list of specific outcomes with specific acceptance criteria — that fits on one page.

5. Missing acceptance criteria

Deliverables without acceptance criteria are deliverables the vendor can declare complete at will. Every deliverable in the proposal should be accompanied by a specific, testable acceptance criterion: "the login endpoint responds in under 200ms at p95 for 500 concurrent users" is a real criterion. "The login system is production-ready" is not.

6. Timelines in phases, not dates

"Phase 2 begins after Phase 1 completes." Fine, but when does Phase 1 complete? Every phase should have an outside date, a named milestone, and a defined slip protocol. Timelines that are self-referential ("Phase N ends when Phase N is done") are not timelines.

Team and staffing red flags

7. Nameless resumes

If the proposal lists "one senior engineer, five years of experience" instead of a named engineer with a real resume, you are being sold the vendor's bench in the abstract and will be staffed with whoever is available on day one. Ask for the named team pre-signature. Reserve the right to interview and reject.

8. Overlapping allocations

Ask what other engagements the named team members are on. A "senior engineer" allocated 40% to your project and 60% to two other clients will not deliver like a senior engineer. Get percent allocations in writing.

9. No named engineering manager on the vendor side

The single most important role on a client engagement is the engineering manager from the vendor who owns the outcome. A proposal with an anonymous "delivery lead" and no name attached is a proposal where nobody is accountable when things go sideways.

Legal and commercial red flags

10. Weasel-worded SLAs

"We will endeavor to respond to critical incidents within four hours." Endeavor is not a commitment. Real SLAs commit to response time and remediation time, and specify credits or exit rights when they are missed.

11. IP assignment that isn't

Read the IP clause carefully. "The vendor grants the client a license to the deliverables" is not the same as "the client owns the deliverables." On any custom software build you are paying for, work-made-for-hire with full IP assignment is the baseline. Anything less should be a conscious, negotiated exception.

12. Auto-renewing terms with buried price hikes

Standard in SaaS, occasionally sneaking into services proposals. Any auto-renew clause needs a defined cap on the renewal price and a notice window long enough to actually switch vendors if you want to.

13. Non-solicitation clauses that are actually non-hires

A reasonable non-solicit says the client will not proactively recruit vendor employees during the engagement. An unreasonable one says the client cannot hire a vendor employee for twenty-four months even if the employee approaches the client first. The unreasonable version is a hostage clause and should be negotiated down to twelve months with an approached-first carve-out.

Communication and process red flags

14. Reporting cadence measured in weeks

Any engagement of meaningful scope should include weekly written status, monthly executive review, and real-time access to the working artifacts (repository, ticket board, deployment logs). Vendors who report monthly are hiding the middle of the sausage.

15. Change orders without a defined process

The scope will change. That is fine. Every proposal should define how change orders are proposed, priced, approved, and logged. Vendors who leave this open-ended are optimizing for the ability to price changes at their convenience.

The one signal that dwarfs all others

Talk to two current clients on comparable engagements before you sign. Not the vendor's cherry-picked references — the two most recent completed engagements with a scope similar to yours. If the vendor cannot or will not produce them, that is the signal. Every other red flag on this list is a subset of the information you would have gotten from those two phone calls.

Bottom line

A software proposal is the vendor's first artifact and, honestly, the highest-signal one you'll get before signature. Read it like a contract, not a marketing document. If it fails on more than two or three of the items on this list, either renegotiate or walk. The cost of a bad proposal accepted is always higher than the cost of a good proposal delayed.