How to Compare Software Development Proposals When the Scopes Differ

Three quotes are only comparable when they describe the same job. One promises a customer portal. Another promises a request form and an office dashboard. Both look like answers to your brief, but you can't tell whether either gets your customer through the whole task.

You don't need to judge the code to start. You need to make each team's commitment visible: what the customer can finish, what your staff must do, what happens when something fails, and who owns the software after release.

Here's how to compare software development proposals when the scopes differ. Work through the unpriced example below, then use the editable comparison worksheet and completed example with your own replies. There's also a printable worksheet and worked example. Keep your suppliers' commercial terms in your private copy.

• Use the same workflow and responsibility rows for every proposal.
• Separate included, excluded, conditional and unanswered commitments.
• Resolve a missing commitment in writing before relying on it.
• Choose the release boundary before choosing the supplier.

Illustrative example. This scenario and both proposals were created for this guide. They don't describe a client engagement, actual suppliers or measured results. Neither proposal includes a price.

A service business wants customers to request a visit online. The customer supplies contact details, an address, a preferred visit window and a photo. Office staff reviews the request, assigns a technician and updates its status. The customer receives confirmation and returns to look up their own request status without contacting the office. The business already has a scheduling system, but hasn't confirmed integration access.

1. Proposal A: a portal with manual follow-up

A includes the request form, photo, email receipt, office list, technician assignment and status controls. Customer status lookup and the scheduling integration are explicitly excluded. Staff will copy confirmed visits into the existing scheduler and communicate later updates manually. Native apps, payments and old-record migration are excluded too.

A names a demonstration and test checklist: submit a request, see it once in the office list with its photo, assign a technician, save a status change and deliver a receipt to the agreed test mailbox. It includes correction and retest against those checks. The supplier deploys to client-owned hosting and supplies the repository, setup notes and an administrator walkthrough. Its defect-support period still needs a duration. Ongoing maintenance needs a separate agreement.

2. Proposal B: customer lookup and a conditional integration

B includes the same request and office features, plus customer status lookup and one-way creation of confirmed visits in the existing scheduler. Customers should see their own requests. The integration depends on provider approval and test access supplied by the buyer. Updates made in the scheduler won't return to the portal. B excludes the same native apps, payments and old-record migration.

B promises testing, client review, deployment, source code, a walkthrough and launch support. Individual acceptance checks, evidence, correction and retest will be agreed at kickoff. Account ownership, recovery arrangements and support coverage aren't specified. Failed transfers, safe retries and duplicate prevention aren't specified either.

B covers more of the requested customer workflow on paper. A defines some delivery checks and handover terms more clearly. Neither is ready to approve as written. A's manual path might fit a pilot if the buyer accepts its limits and staff can operate it. B's integration might be required for the intended release, but the access condition and recovery gaps need resolving first. More features don't settle that decision.

Copy the requested outcome into your worksheet. Then keep two things separate: what each proposal currently says and what you want the revised commitment to say. Preserve the original wording or a short faithful summary with its section reference. A meeting note shouldn't silently replace the proposal.

1. Business outcome and complete workflows

Follow one request from the customer's first action through the staff handoff to the finished result. Include each role, notification and exception that matters to release. In the example, saved status controls for staff aren't the same as a customer being able to look up that status. A feature-name match would hide that gap.

Mark each row required, deferred or unresolved for your first release. You can compare different approaches when they produce the result you need. You don't have to force both teams to use the same technology or copy the larger feature list.

2. Inclusions, exclusions and unanswered questions

Use four labels. Included means an explicit commitment exists. Excluded means the proposal says it won't provide the work. Conditional means delivery depends on a stated assumption. Unanswered means you lack a clear answer. If one sentence contains different commitments, split it into rows.

B's integration is conditional. Its duplicate-prevention behaviour is unanswered. A's integration is excluded. These need different questions. Don't turn a blank into either a promise or an accusation. Ask what the team means, then record its written answer.

3. Dependencies and your responsibilities

For every dependency, name who supplies it, when it's needed and what happens if it doesn't arrive. Include content, business rules, data cleanup, test users, account access and approvals. Confirm that your staff can provide the time and decisions each plan assumes.

In B, scheduling-provider access controls whether the proposed integration can proceed. Ask who contacts the provider, who verifies access and who approves a revised plan if it fails. In A, manual entry belongs to the office. That is work your business must accept, even though it isn't software development.

4. Acceptance criteria and evidence of completion

Ask what you'll check, who accepts it, what evidence you'll receive and what happens when a check fails. The UK Government Service Manual's acceptance guidance describes criteria as outcomes used to confirm that the service meets a user need. Apply that to each promised workflow.

For this example: a valid request appears once with the correct photo; an invalid address produces a useful error; another customer can't view the request; a failed scheduler transfer is visible to staff and can be recovered without creating a duplicate visit. Those last checks are clarification requests, not things either proposal has already promised.

A working demonstration proves the cases it exercises. It doesn't prove security, accessibility, performance or maintainability in full. Ask which reviews and tests are included, their scope and who can assess the evidence. Get focused technical help where a claim materially affects the purchase and you can't judge it.

5. Release, account ownership and handover

Separate deploying the software from authorizing go-live. Record who runs the release, checks it, restores the previous version if needed and verifies a backup can be restored. List the repository, hosting, domain, email and other service accounts, with the owner, administrator access and transfer conditions.

Ask what the next team receives: source code, setup and deployment instructions, data export, known issues and a walkthrough. Request any restrictions on reuse or third-party components. Owning source code doesn't by itself establish that your team controls the accounts or can operate the product.

6. Maintenance and post-launch responsibility

Turn launch support into named coverage: when it starts and ends, which defects qualify, who responds, during which hours and with what response expectations. Separate it from new features and continuing maintenance. Ask who owns monitoring, security updates, backup checks, third-party changes and user support after that period.

The UK Government Service Manual's monitoring guidance connects checks, alerts and issue handling to support obligations. For your comparison, the useful question is who acts when a check fails. A monitoring tool without an agreed responder leaves that responsibility open.

7. Clarification questions and unresolved risks

Give every open issue an owner and a point when it must be settled. Record the supplier's reply, its revised scope reference, the remaining consequence and your decision. A reply saying we'll discuss it later keeps the row open. An exclusion can be acceptable if your business deliberately accepts it and appoints someone to handle the work.

The workbook contains the full illustrative proposals, a completed comparison and an open-questions log. This shorter table shows the decisions the comparison exposes. Scroll across on a phone.

The next decision belongs to the buyer: can staff operate a deliberately manual first release, or does the product need the integrated workflow from day one? Ask for revised proposals against that choice. Keep the supplier's original alternative beside the common version so you can see what you gain or give up.

Then compare the commercial terms privately for that defined commitment: what's included in the total or estimate, payment milestones, limits, third-party running costs, change approval and the consequence if an assumption fails. Don't add an invented allowance for missing work. Ask the supplier to state the effect or leave it unresolved. A lower quote can be the right choice. A higher quote can contain work you don't need. Neither conclusion follows from the number alone.

The broader contract argument belongs in fixed price versus hourly. Keep this comparison attached to the work you're actually considering buying.

The team questions belong in choosing a development partner.

A supplier can clarify an omission in writing. It can't responsibly confirm an integration it hasn't been allowed to inspect. In this example, provider access might change the proposed release. Repeatedly requesting a firmer full-build quote won't resolve that dependency.

Ask for a bounded discovery that answers the specific open question. Define the access needed, the person doing the investigation, its duration and commercial limit, the evidence you'll receive, and the decision that ends it. For scheduling, that could be a verified access check, a test of creating a visit, documented failure/recovery options and a revised scope. Agree what happens if access is refused.

Rigoris's discovery process produces portable flows, boundaries and acceptance criteria. The full method belongs there. Here, the rule is to buy enough investigation to settle the dependency before treating an uncertain build as a comparable commitment.

Send the common outcome and worksheet to each team. Tailor the rows to what it actually proposed. You can use this wording:

Please confirm the first-release outcome and complete workflow in the attached comparison. For each row, mark included, excluded, conditional or unanswered and cite the proposal section.

Please state our required inputs and dates; acceptance checks, evidence and correction/retest; release and recovery responsibility; account ownership and handover; and support and maintenance coverage. Identify the effect of each clarification on delivery and commercial terms, or the bounded investigation needed to answer it.

Please return a revised proposal with a version/date and identify which written scope and terms will govern the commitment. We'll keep unresolved items open until the revised terms are accepted.

Use the worksheet's decision field for what you accept, defer or still need answered. Don't average away a required workflow that one proposal can't provide.

Bring one unclear workflow or proposal question to a scoped conversation. If an existing proposal or build needs independent examination, start with a software build second opinion to agree the review boundary and evidence needed. Start with the row that's stopping you from deciding.