How to Compare Software Development Proposals

How do we compare three software development proposals apples to apples?

To compare three software development proposals apples to apples, first rewrite each one against a single requirement list that you own, so every vendor is priced on the same scope. Then line up the pricing model, stated assumptions and exclusions, named team and seniority, discovery and change process, intellectual property and code access terms, security practices and support after launch. Fill the gaps by sending every vendor the same written questions. Score the answers with weights you set before reading the prices, and treat a low total that rests on missing scope as a risk, not a saving.

The total price is the last line to compare, not the first. Until scope, assumptions and exclusions match, the three totals describe three different projects.

Why do proposals for the same project look so different?

Proposals differ because each vendor reads a loose brief its own way, prices its own risk and picks its own commercial model.

• Interpretation: "Users can book appointments" can mean a simple request form or a calendar with reminders, rescheduling and payment.
• Risk: A fixed price carries a buffer for unknowns, while a time and materials quote leaves that risk with you.
• Omission: Some vendors leave out design, testing, deployment or project management and add them later as extras.
• Depth: A proposal written in an afternoon reflects less understanding than one written after a scoping call with your team.

How do you normalize scope into one requirement list?

Build one requirement list yourself, then map every proposal onto it line by line. Each vendor's document is then read against your list instead of against the other two.

• 1. Collect: Pull every feature, integration and report from the three proposals and your brief into one list.
• 2. Split: Break broad items into pieces a user would notice, for example sign up, password reset and roles instead of "user management".
• 3. Mark coverage: For each proposal, mark every line as included, excluded, assumed or not mentioned.
• 4. Add quality needs: Add performance, accessibility, supported devices, data migration and test environments, which proposals often skip.
• 5. Send it back: Share the merged list with all three vendors and ask each to confirm or re-quote against it.

Step five does the real work. Once every vendor prices the same list, a gap between totals means something, and a vendor that will not re-quote has shown how it is likely to handle change.

How do you compare fixed price and time and materials estimates?

Put every estimate into the same view: what is promised, what it costs if the assumptions hold, and what happens when they do not. A fixed price moves scope risk to the vendor; time and materials keeps it with you in exchange for flexibility.

• Fixed price: Check what the price is fixed against: the requirement list, acceptance criteria, review rounds and how change requests are charged.
• Time and materials: Ask for the estimate behind the rate, broken down by feature or milestone, with a low and high range.
• Milestone payments: Payment follows accepted deliverables, so check how acceptance is defined and how long you have to review.
• Assumptions: Copy every assumption, such as "client provides API access" or "designs supplied". Each one becomes a change request if it proves wrong.
• Exclusions: Note what each leaves out, such as QA, DevOps, app store submission, third-party licenses or hosting, and price those gaps before comparing totals.

Ask each vendor what would make its number badly wrong. Naming specific risks shows it has studied the work.

What should you check about the team and its seniority?

Check who will do the work, how experienced they are and how much of their week your project gets. The people who pitch are often not the people who build.

• Named roles: Technical lead, developers, QA, designer and delivery manager, each with a name or a profile.
• Seniority mix: How many engineers are senior, mid-level and junior, and who reviews the junior engineers' code.
• Allocation: Whether each person is full time on your project or shared with other clients.
• Continuity: How the vendor replaces someone who leaves, and who pays for the handover.
• Meet the lead: A call with the technical lead before you sign, not only with sales.

Compare rates per role only once the mix is clear. A low blended rate built on junior engineers can cost more in rework than a higher rate with a senior lead.

How do the discovery and change processes compare?

Compare discovery by what it produces, and change control by how a new request is estimated, approved and billed. Together they decide how the project behaves once reality departs from the proposal.

• Discovery output: Written requirements, user flows, an architecture outline, a risk list and a revised estimate. Ask for a redacted sample.
• Portability: Whether the discovery output is yours to keep and to take to a different vendor.
• Change path: Who can raise a change, who approves it and when work on it starts.
• Trade-offs: Whether a new item can replace one of similar size without a price change.

Skipping discovery on a complex product does not make it cheaper. The discovery still happens inside the build, where each finding arrives as a change request.

Who owns the code, and can you access it?

Ownership and access belong in the contract, not in the sales deck. Look for an explicit transfer of intellectual property to you, code held in repositories you control, and a list of anything the vendor keeps.

The U.S. Copyright Office's Circular 30 explains that a commissioned work counts as made for hire only when it falls into one of nine listed categories, such as a translation, a compilation or a test, and the parties expressly agree to it in a written instrument they both sign. When a work qualifies, the commissioning party is treated as both its author and its copyright owner.

Software is not named on that list. Check that each contract carries a written assignment of rights, and have your own counsel review the clause instead of relying on a "work for hire" label.

• Repositories: Code sits in your Git account from the first commit, with the vendor as a collaborator.
• Pre-existing code: The vendor lists frameworks or tools it brings in and the license you receive for them.
• Accounts: Hosting, domains, app store listings and paid services are registered in your name.
• Handover: Documentation, build scripts and credentials arrive with the code, not on request at the end.

What security and compliance questions should every vendor answer?

Every vendor should explain how it builds security in, how it proves it, and how it treats any regulated data you hold. Send all three the same questions.

The Secure Software Development Framework (SSDF), published by NIST in February 2022 as SP 800-218 Version 1.1, sorts its practices into four groups: Prepare the Organization, Protect the Software, Produce Well-Secured Software and Respond to Vulnerabilities. NIST states that because the SSDF gives a common vocabulary, software acquirers can use it to foster communications with suppliers in acquisition processes.

The OWASP Application Security Verification Standard (ASVS), at version 5.0.0 since 30 May 2025, names use during procurement as one of its purposes: a basis for specifying application security verification requirements in contracts.

• Practices: How does the team's secure development work map to the four SSDF groups?
• Verification: Which ASVS level will the build be tested against?
• Access: Who can reach production and real data, and is that access logged and removed on exit?
• Regulated data: Which rules apply to your data, and which agreements, such as a HIPAA business associate agreement, will the vendor sign?

Ask for evidence, not adjectives. A sample threat model or a redacted penetration test summary tells you more than a page of assurances.

What support after launch should a proposal include?

A proposal should state what happens after go-live: a warranty for defects, ongoing support terms and the cost of keeping the software current. Many stop at launch, which hides the running cost.

• Warranty: How long post-launch defects are fixed free, and what counts as a defect rather than a feature.
• Support terms: Hours of cover and response targets by severity.
• Maintenance: Security patches, dependency upgrades and app store policy changes.
• Exit: How code, documentation and access move to you or a new team.

What red flags should you look for in a software proposal?

The clearest red flags are a price with no scope behind it, a team with no names, and terms that keep your code or accounts with the vendor.

• Vague scope: Features listed as headings, with no acceptance criteria or exclusions.
• Instant certainty: A firm price for a complex product with no questions asked.
• No assumptions: A proposal that lists none has hidden them or not thought of them.
• Withheld access: Repositories or hosting in the vendor's name, or code you cannot see until the final invoice.
• Swapped team: Senior people in the pitch who are missing from the delivery plan.

One red flag does not rule a vendor out. Raise it in writing and judge the reply.

What are the best practices for scoring software proposals?

Score each proposal against criteria and weights you fix before opening the prices, and judge cost on its own line. Writing the weights down first stops a low number from reshaping what you think matters.

• Scope fit: How fully the proposal covers your requirement list and states what is out.
• Estimate quality: A broken-down estimate with realistic assumptions and named risks.
• Team: Seniority, allocation and whether you met the people doing the work.
• Process: Discovery, change control and how often you see working software.
• Ownership: Assignment of rights, repository control and handover terms.
• Security: Answers to the shared questions, backed by evidence.
• Adjusted cost: The quoted price plus exclusions and a realistic allowance for change.

Set the weights for this product: a regulated product may weight security most, an early prototype speed of learning. Have two or three people score separately, then discuss the gaps instead of averaging them away.

How Agnotic can help

Agnotic Technologies can make the comparison easier before the quotes go out. A product discovery sprint with Agnotic produces the requirement list, risk list and architecture outline that vendors can price against, so the proposals you receive answer the same brief.

When Agnotic is on your shortlist, expect the same questions answered in writing: the named team, assumptions and exclusions, ownership terms and the support plan. For an inherited codebase, an Agnotic code audit gives an independent view before you commit.

Sources

• U.S. Copyright Office: Circular 30, Works Made for Hire
• NIST SP 800-218: Secure Software Development Framework (SSDF) Version 1.1
• OWASP: Application Security Verification Standard