A polished proposal can hide an unclear delivery model. Twelve questions that make the model visible - and a way to score the answers.
General information only, current as at the date of publication - not legal or procurement advice. Full note at the end of this article.
Proposals are written to be compared, which is exactly why they stop being useful at the point of comparison. Two teams quoting the same scope at a similar price can carry entirely different risk, and the difference does not appear in the document. It appears four months later, in how the work actually runs.
The questions below are designed to surface that difference before the signature rather than after it. They cover four areas - discovery, delivery, controls and handover - and each has an answer that separates a team with a delivery model from one with a sales deck. We would be comfortable being asked all twelve, and we would expect any serious software engineering partner to be as well.
Questions 1 to 3 are about discovery, and everything downstream depends on them. A partner who gets discovery wrong does not find out until the estimate fails, by which point the discovery budget has already been spent.
A credible partner separates facts, assumptions and open decisions, and can tell you which ones it needs to close before confirming scope, architecture or cost. Watch for the opposite: an estimate delivered quickly and confidently, with the assumptions left implicit. That number is not wrong yet, but nobody can say what would make it wrong.
Screens and user stories describe the surface. The team should be asking about triggers, decisions, exceptions, data, owners and operational consequences - particularly the exception path, which is where most of the real cost lives and most of the questions stop. If you already have developers in-house, ask specifically how the partner's team will work alongside them, because an unstated answer to that usually becomes a boundary dispute in month two.
Look for dependency mapping, interface analysis, data ownership and a transition plan. Be careful with a proposal that assumes a clean-slate rewrite without evidence that a rewrite is the cheaper path - a rewrite is the most expensive way to discover why the old system did something strange.
Questions 4 to 6 move from discovery to delivery. They test the same thing from different angles: whether you can tell how the project is going without being told.
The answer should go well beyond "we have QA." Ask about acceptance criteria, code and design review, automated and exploratory testing, performance and security testing, defect trends and release evidence. The useful follow-up is which of those apply to a change that touches money or customer data, and which do not - a team that applies identical rigor everywhere has not thought about risk, it has bought a process.
Material decisions should record context, options considered, trade-offs, owner and consequence, and you should be able to review and keep them. This matters most at the moment it is least convenient: when someone asks, two years in, why the system does something that now looks wrong.
Progress should be visible in working increments, risks, decisions and outcomes rather than in utilization or percentage-complete figures. Percentage complete is the one number that cannot be verified from outside, and it hides integration risk longest. DORA's software delivery metrics are a reasonable external reference for what delivery health looks like, though they describe a team's throughput and stability rather than whether it is building the right thing.
Questions 7 to 9 cover controls - what happens when something goes wrong, or when someone asks. This is where the gap between a presentation and an operating model is widest, because the answers depend on having done it rather than having planned it.
Ask which requirements enter architecture, backlog, tests, release approval and monitoring, and ask for example artifacts with confidential details removed. NIST's systems security engineering guidance is a useful reference point for what that looks like structurally. The warning sign is security described entirely through certificates: a certificate tells you an organization passed an audit, not that a requirement will reach the backlog on your project.