How to review a software proposal without missing the risky assumptions

A software proposal can look polished and still be built on sand. The dangerous part is that the riskiest problems usually aren't hiding in the code section — they're tucked into quiet little assumptions about your data, your staff, your deadlines, and what "done" supposedly means.

I've read enough proposals to tell you this: the biggest risk is often what sounds obvious. If you review a proposal like a menu instead of a construction plan, you'll miss the load-bearing walls.

1. Start by asking, "What has to be true for this plan to work?"

Every proposal has hidden assumptions, even good ones. Your job is to pull them into daylight. Ask the developer to list the top assumptions about requirements, data, integrations, user behavior, and decision-making.

If they can't do that, don't do that project yet. A proposal should read partly like a build plan and partly like a risk document, because that's what it is.

2. Check whether the problem is actually defined clearly

A lot of proposals jump straight to features: dashboard, portal, admin panel, mobile app. That's like hiring a contractor who starts talking about granite countertops before checking whether the foundation is cracked.

Look for a plain-English statement of the business problem, who has it, and what the software is supposed to improve. If that's fuzzy, the estimate is fuzzy too. This is why I usually tell people to read 6 things to clarify before you ask a developer for an estimate before they compare bids.

3. Look for the assumptions about your existing data

Bad data can wreck a software project faster than bad code. If the proposal assumes your spreadsheets, CRM records, or exported reports are clean and consistent, that needs to be stated out loud.

Ask: who is responsible for cleaning, mapping, and validating data before it goes live? If the answer is vague, expect delays, rework, and finger-pointing.

4. Treat integrations as a separate risk, not a footnote

If the proposal says it will "integrate with QuickBooks," "sync with your CRM," or "connect through API," stop there and dig in. Integrations are where simple projects go to get complicated.

You want specifics: what system, what data, how often it syncs, who owns failures, and what happens when the third-party system changes. If you need a primer, read What a software integration actually is—and why vendors oversimplify it. And if integration is central to the job, it should be clearly addressed in the plan, not waved at like magic under API Integrations.

5. Review what is out of scope more carefully than what is in scope

This is where a lot of surprises live. Migration, training, reporting, monitoring, bug fixes after launch, user permissions, and support often get pushed into the shadows under "out of scope" or "future phase."

Read that section slowly. Out of scope doesn't mean unimportant — it often means "you'll pay for this later when you're under pressure."

6. Check for non-feature requirements

A proposal shouldn't only describe what the software does. It should also describe how well it needs to work: security, uptime, performance, backups, access control, audit trails, accessibility, and recovery if something breaks.

This is the part business owners skip because it isn't flashy. Don't skip it. According to Verizon's breach research, vulnerability exploitation remains a major entry point in real-world breaches, so proposals that barely mention patching or security maintenance are not serious proposals.

7. Be suspicious of timelines that look too clean

If a proposal gives you a perfectly precise timeline on a messy project, I get nervous. Real software work has unknowns, especially around integrations, legacy systems, and changing requirements.

McKinsey and Oxford have reported that large IT projects regularly run over budget and underdeliver value. That doesn't mean every project is doomed. It means certainty theater is not the same as risk control.

8. Ask how assumptions will be tested early

A strong proposal doesn't just estimate the work; it explains how the risky parts will be validated early. That might mean discovery, a prototype, a technical spike, staged rollout, or building the hardest workflow first.

This is one reason I prefer phased work on many custom software projects. Fixing a bad assumption in week two is cheap. Fixing it after launch is like tearing out finished drywall to move plumbing.

9. Check who is expected to make decisions on your side

A proposal can fail because your team isn't available, your operations lead is too busy, or nobody owns final approval. Those are business risks, not coding risks, but they matter just as much.

The proposal should name what input is needed from you, how often, and who signs off. If you're a business in Northwest Arkansas, this matters even more when you're juggling fast growth and thin teams.

10. Review the change-request and acceptance rules before price

Most owners jump to the number first. I get it. But the terms around changes, approvals, rework, and acceptance criteria often matter more than the initial quote.

Ask what happens if requirements change, if something was misunderstood, or if a feature technically works but your team hates using it. Also compare the billing model carefully — Fixed price vs hourly: which billing model protects you is worth reading before you sign anything.

11. Look for evidence, not just confidence

A developer doesn't need to pretend every answer is known on day one. What you want is proof of thinking: named risks, validation steps, technical reasoning, and a clear explanation of trade-offs.

A proposal with some uncertainty handled honestly is safer than one that promises the moon in tidy bullet points. The Standish Group's long-running CHAOS research has made this pretty clear: software projects get into trouble all the time, so blind confidence is not a quality signal.

12. Add up the cost after launch

The build price is only the entry fee. Hosting, monitoring, support, bug fixes, security updates, third-party subscriptions, and future changes can easily matter more over time.

Ask for a plain-English view of ongoing costs and responsibilities. Then make your decision based on total ownership, not just the sticker price.

A good software proposal should make risk easier to see, not easier to ignore. If you review one this way, line by line, you'll catch the assumptions that turn "reasonable" projects into expensive cleanup jobs. My honest recommendation: don't approve a proposal until the unknowns are named, the risky assumptions are testable, and the out-of-scope section doesn't hide the real work.