Why can two matching feature lists describe different projects?
A feature list names visible outputs, but it rarely defines the work needed to make them dependable. Two proposals may both include accounts, payments and reporting while making different assumptions about discovery, data migration, integrations, security, testing, acceptance and support. Compare the responsibilities behind each feature before treating the scope or price as equivalent.
Find the assumptions doing hidden work
One supplier may assume clean source data, a documented third-party API and prompt stakeholder decisions. Another may include data profiling, integration investigation and facilitated decisions. Both can quote the same feature, yet they have priced different uncertainty. Ask each supplier to list the information, access, client time and external behaviour their plan depends on.
Compare an important journey end to end
Choose one consequential workflow and trace it through every proposal. For an ordering product, that might include creating the order, taking payment, handling a delayed result, changing stock, notifying staff and reconciling a mismatch. This exposes whether a proposal covers a complete business outcome or only the most visible screens.
How should the proposals be normalised before price is compared?
Create one comparison sheet organised around outcomes, exclusions, dependencies and evidence. Translate supplier terminology into the same business journeys, then mark who owns discovery, content, data, environments, integration access, quality assurance, deployment and training. The aim is not to force identical delivery methods; it is to reveal which responsibilities and risks sit inside each total.
Use ranges where certainty is not available
An honest proposal may leave a bounded range around an untested integration or migration. Do not automatically favour false precision. Compare how each supplier intends to reduce the uncertainty, when the estimate will be revisited and what happens if the assumption proves wrong. A small discovery stage can be more informative than padding every unknown.
Separate required outcomes from optional polish
Identify what must work for the investment to create value, what protects the operation and what can follow later. Then ask suppliers to map their phases to those priorities. This makes a lean, well-sequenced proposal comparable with a larger proposal and shows whether an attractive total relies on postponing necessary operational work.
What should a proposal say about acceptance and evidence?
A useful proposal explains how both sides will know that an agreed outcome works. It should connect important journeys to observable acceptance evidence, identify who reviews it and state what happens when work does not meet the agreed condition. A promise to test the product is weaker than a clear account of the behaviours, environments and responsibilities that testing covers.
Ask for evidence at the level of risk
A marketing page and a payment workflow do not need the same acceptance process. For a payment flow, evidence may include authenticated events, duplicate-event handling, reconciliation and a recovery drill. For a data migration, it may include record counts, sampled comparisons, exception reports and a rollback plan. The proposed checks should follow the consequence of failure.
Clarify what complete means
Ask whether completion includes production deployment, configuration, monitoring, documentation and knowledge transfer. Confirm which browsers, devices, roles and environments are included. Define who supplies test data and who can accept a release. This prevents a technical handover from being mistaken for a working operational transition.
Which ownership and operational terms matter after launch?
Compare who owns the code, designs, infrastructure accounts, data, documentation and third-party subscriptions, and when that ownership transfers. Then examine support hours, response expectations, security updates, monitoring, backups, incident responsibilities and exit assistance. A lower build price can create a more expensive dependency if the business cannot inspect, operate or move the product later.
Treat security as part of the product
General company policies or compliance statements do not explain how this product will handle authentication, sensitive records, dependencies or vulnerability response. Ask for the controls relevant to the proposed system, who implements them, which evidence is provided and which continuing responsibilities remain with the business. Procurement guidance increasingly treats those product-level questions as part of supplier evaluation.
Make the exit path visible
A proposal should state how the business receives current source code, deployment instructions, credentials, data exports and operational knowledge. Clarify any proprietary components or licences that cannot transfer. You may intend a long relationship, but a practical exit path is evidence that the delivery model does not depend on hidden access or undocumented knowledge.
How should a business make the final decision?
Score each proposal against a short set of weighted business criteria, then hold a clarification session around the largest differences. Consider confidence in the team, understanding of the workflow, risk reduction, delivery evidence, operating fit and total likely cost—not simply the quoted total. Record the decision, unresolved assumptions and the conditions that would trigger a change in plan.
Use questions that invite specific answers
Ask what the supplier believes is most uncertain, which assumption could change the estimate most, what they deliberately excluded and how they would prove the riskiest workflow first. Specific answers reveal judgement and candour. A confident presentation matters less than whether the team can explain trade-offs and adapt its recommendation when new evidence appears.
Compare the likely outcome, not the page count
A detailed proposal can still avoid the decisive questions, while a concise one may define them well. Twofold's architecture and discovery work can help a business turn its workflows, constraints and risks into a comparison frame before appointing a delivery partner. The useful result is a decision whose assumptions remain visible throughout the build.