Software Development Proposal Red Flags: 6 to Check Before You Sign

It's Thursday afternoon and the steering committee meets Monday. Three proposals sit in the shared drive for the same build. The cheapest is less than half the price of the dearest.

You've read all three twice. Each has a confident timeline, a polished case study and a team that sounds senior. No two are structured the same way, so nothing lines up side by side.

Why the price gap is mostly a risk gap

Three vendors quoting the same brief are pricing the same unknowns. The real difference is who carries them. A low quote often assumes the easy version of every unknown, and the hard version comes back later as a change request.

Overruns are the norm at scale, not the exception. McKinsey and the University of Oxford studied more than 5,400 IT projects. Large projects, those over US$15 million, ran 45% over budget on average and delivered 56% less value than predicted.

The six red flags

1. A fixed price with no assumptions

A fixed price is only as firm as the assumptions under it. 

2. No acceptance criteria

Without agreed criteria, "done" is whatever the vendor says it is.

• What it looks like: features described as nouns, like "user dashboard" or "reporting module", with no test of when each is finished.

• What good looks like: each feature has criteria you could check yourself, and the proposal says who signs off.

3. No named team or location

You're buying people, not a logo. If you can't see who builds it, you can't judge seniority.

• What it looks like: "a dedicated team of experts" with no roles, names or locations.

• What good looks like: named leads, the roles on the team, where each person works and how much of their time is yours.

4. Unclear IP or repository ownership

In Australia, contractors generally own the copyright in software they write unless a written agreement assigns it. Silence in a proposal is not a small gap.

5. Thin testing

Testing is the first thing cut to win on price, and the last gap you notice. DORA's guidance puts it plainly: no one should declare work complete unless automated acceptance tests are passing.

• What it looks like: a single "QA" line item, or testing scheduled as a phase at the end.

• What good looks like: automated tests run with every change, plus named acceptance testing with your team.

6. Nothing after launch

Launch is where real users find the problems testing missed.

• What it looks like: the proposal ends at go-live, with support "available on request".

• What good looks like: a defined warranty period, a clear defect-versus-change line, and support with response times.

When this level of scrutiny is overkill

Not every job needs a six-point review. A small, low-risk change with a trusted vendor can run on a short quote and a clear email. So can a throwaway prototype that never meets a customer.

If a vendor already maintains your system well, their track record is better evidence than any proposal. Save the scorecard for builds that touch customers, money or regulated data, or code you'll live with for years.

The six-flag scorecard

Score each proposal 0, 1 or 2 per row: missing, vague, or written and specific. 

The total matters less than where the zeros sit. In an illustrative fintech comparison, the cheapest proposal scores 7 out of 12, with zeros on assumptions and after launch. The dearest scores 10, but its team row is vague.

Now you have precise questions for each vendor, not a gut feel. Next, send every vendor the combined assumption list and ask them to re-quote against it. The gap usually narrows, and what's left is a real difference in approach. 

What makes software prices vary

Prices for the same brief differ for four main reasons. None is a sign of value on its own.