Compare proposals against the same workflow and acceptance examples before comparing prices. A lower quote may describe a smaller or less complete delivery.
Prepared with AI assistance. These are practical scoping recommendations; examples are illustrative, not client results.
Normalize the scope
Create a short comparison sheet with users, records, actions, integrations, migration, and operational support. Ask each supplier to mark included, excluded, or unresolved. Avoid a points system that rewards a long feature list: a single missing handoff can matter more than several optional screens.
Use the same comparison sheet for every supplier. For each row, record included, excluded or unresolved, together with the proposal section that supports the answer. The table below defines the evidence to request; it does not score or endorse a vendor.
| Decision | Evidence to request | What an unresolved answer can hide |
|---|---|---|
| Complete workflow | One normal request and one exception, from intake to completion, with a named user at each step. | A polished screen that still leaves the final handoff manual. |
| Data and connections | A list of imports, external systems, access assumptions and who fixes rejected records. | Migration and integration work that is absent from the quoted scope. |
| Acceptance | An agreed demonstration using representative records, plus a named person who accepts the release. | A milestone that means code delivered rather than work the team can complete. |
| Ownership and handover | Who controls the repository and hosting, what documentation is delivered and how another team takes over. | Ongoing dependence on access or knowledge held only by the supplier. |
| Changes and support | The process for approving added work, the defect boundary, support hours and response commitments. | A low initial quote with unclear operating costs or slow recovery. |
| First-year cost | One-time fees, recurring charges and internal effort, with assumptions and exclusions visible. | Comparing a build-only price with a complete delivery and support arrangement. |
Compare proof of completion
For each milestone, ask what you will be able to do and how you will verify it. A demonstration with prepared data is different from a release your staff can use. Require clarity about who supplies test records, who accepts the work, and what happens when the agreed example fails.
Examine ownership after launch
Record who controls the source repository, hosting account, backups, and deployment process. Treat answers as proposal items to resolve, not assumptions about how all vendors work. Ask for the expected support arrangement and the boundary between a defect and a new request. Contract terms should reflect the final commercial agreement.
Make the decision explainable
Write a one-page recommendation that identifies scope differences and unresolved risks. If one supplier is more expensive because migration and staff onboarding are included, show that explicitly. Your internal sponsor should be able to understand the choice without attending every sales call. Keep open questions visible until they receive a written answer.
For example, proposal A may include the portal screens while proposal B also includes data cleanup, account recovery and launch support. Before choosing the lower number, ask A to price those same obligations or document that your team will provide them. If both proposals meet the same acceptance cases, the less expensive option may be the right choice.