How to compare software development quotes after you raise

You closed the round. The board expects a first release or a v2 by a date you helped set, and you now have three proposals on your desk. One total is far lower than the others, one is far higher, and the middle one reads well but says little.

The instinct is to pick the middle number and move on. That works only if the three quotes describe the same product, built by the same shape of team, with the same risks priced in. They rarely do. Many founders arrive here after a first build went wrong, describing themselves as having "a working MVP that outgrew the outsourced dev team who built it" (HN).

This guide helps you decide which proposal to trust. It covers what drives the number, how to put quotes side by side, which signals matter, and how to write a contract around software you can show the board.

Step 1: Understand what actually drives the number

A quote is a set of assumptions multiplied together. Before you compare totals, find out which assumptions each vendor made. Six usually move the number most.

• Scope. Which user journeys are in the first release, and how finished each one is. "User accounts" can mean email sign-in or a full permissions model with teams and roles.
• Team shape. Who works on the project, for how long, and how much of each person's week. A senior lead for two days a week costs and delivers differently from a full-time junior team.
• Rates and billing model. Fixed price, time and materials (you pay for hours worked), or a capped mix. Each moves risk between you and the vendor.
• Risk allowance. Time set aside for the unknowns: an integration with a partner's system, a data migration, an approval from an app store.
• Exclusions. What the quote leaves out. Design, testing, hosting setup, analytics and security reviews are common gaps.
• Ongoing costs. Hosting, third-party services, licences, support and maintenance after launch. These continue after the build invoice is paid.

A low quote is often a narrow scope with large exclusions. A high quote may include work the others left for you to discover later. Neither total tells you which is which.

Step 2: Ask every vendor the same questions

You cannot normalise quotes that answer different questions. Send each vendor the same written request before you compare anything. Ask them to answer in their own words, and to flag where they disagree with your brief.

Subject: [Company] build proposal: assumptions we need to compare quotes

Thank you for your proposal. Before we decide, we are asking every vendor the same questions so we can compare like with like. Please answer each one briefly.

1. Scope: list the user journeys included in the first release, and mark any you consider out of scope or later work.
2. Team: name each role, the expected weekly time, and who is the day-to-day lead.
3. Billing: fixed price, time and materials, or capped. What happens if scope changes?
4. Risk: which parts of [product] do you see as most uncertain, and how much time is set aside for them?
5. Exclusions: what is not included (design, testing, hosting setup, security review, app store submission, data migration)?
6. Running costs: expected monthly hosting, third-party services and licences after launch, and your support terms.
7. Milestones: what working software will we be able to use at each payment point?
8. Ownership: when do we receive the code, accounts and documentation, and in what form?

We expect to decide by [date]. Thank you.

The answers matter as much as the content. A vendor that pushes back on your brief, or asks a question you had not thought of, is showing you how they will work. A vendor that answers every line with "included" is telling you something too.

Step 3: Normalise the quotes and read the signals

Put the answers into one document with a section per assumption and a line per vendor. You are not looking for the cheapest line. You are looking for gaps: a missing role, an excluded test phase, running costs nobody mentioned. If it helps to see how scope and team inputs move a planning estimate, the planning calculator lets you change one assumption at a time.

Once the gaps are visible, read each proposal for these signals.

Red flags

• A total with no breakdown. You cannot challenge or adjust what you cannot see.
• Every feature included at the same depth. Real teams tell you what to build first and what to defer.
• Milestones defined as activities. "Design phase complete" or "sprint 4 finished" describes effort, not working software.
• Vague ownership. Code, hosting accounts and domains should be in your name from the start.
• No named lead. If nobody owns the delivery, nobody explains it to you when it slips.

Good signs

• Questions about your users before your features. The vendor wants to know what the first release must prove.
• Stated risks with a plan. "The payments integration is the riskiest part, so we build it in the first month."
• A clear change process. You know how a new request is priced and approved before it happens.
• Early working software. Something you can click through within the first weeks, not at the end.

A common belief is that "a higher quote means a better team". Sometimes it does. More often the higher number reflects different assumptions, which the normalised view will now show you.

Step 4: Tie the contract to software the board can see

Founders worry that an agency's incentive is billable hours, not outcomes. One agency owner put the risk bluntly: the incentive can be "to keep running the project until the client is out of m[oney]" (HN). The answer is a contract where payment follows working software, not time spent.

Write each milestone as something a user can do. "A new customer can sign up, create a project and invite a colleague on the staging site" is a milestone. "Back end mostly done" is not. Your board does not need to understand the technology to see a demo of a user completing a task.

Then require a weekly update in a fixed format. It keeps delivery visible and gives you material for your own investor updates.

Week of [date], [project name]

1. Working now: what a user can do this week that they could not do last week, with a link to try it.
2. Next week: the one or two outcomes we expect to show.
3. Decisions needed from [founder name]: listed with a date by which we need an answer.
4. Risks: anything that could move the next milestone, and what we are doing about it.
5. Scope changes: requests added or removed, and their effect on time and cost.
6. Budget: time used against the plan for this milestone.

If a vendor resists a weekly update with a link to working software, treat that as an answer.

Step 5: Decide between in-house and a partner

Many founders believe that hiring in-house is always better. It can be, once you know what you are building and need people who will own it for years. Before that point, recruiting takes time that your milestone may not have, and a first hire without technical direction can struggle.

A partner fits when you need a first release on a fixed timeline, when the scope is still being shaped, or when you need senior judgment you cannot yet hire. In-house fits when the product is stable, the roadmap is long and the knowledge must stay inside the company. Many teams do both: a partner builds the first release, then hands over to a hire with code, documentation and accounts in order.

Common mistakes

• Comparing totals first. Send the assumptions request before you look at the bottom line.
• Accepting milestones written as phases. Rewrite each one as a task a user can complete on a staging site.
• Forgetting running costs. Ask for monthly hosting, services and support before you sign, and put them in your budget.
• Leaving ownership to the end. Put code, accounts and domains in the company's name from the first week.
• Choosing the vendor that agrees with everything. Favour the one that challenges your scope with reasons.

Questions founders ask

Your next step

This week, send the assumptions request to every vendor on your shortlist and set a reply date. When the answers arrive, put them into one shared document, mark the gaps, and use what you learn to rewrite the milestones in the proposal you prefer.