How to Compare Three Software Quotes: 6 Line Items That Reveal the Real Price
Send the same requirements document to three vendors and the quotes may come back at 300,000, 580,000 and 900,000 yuan. Most companies pick the middle number, reasoning that the cheapest is untrustworthy and the most expensive is unnecessary. That instinct is half right. But if the three quotes were never measured in the same units, the middle price is neither reasonable nor safe — it is just arithmetic on incomparable numbers.
At Juhui Software we have spent ten years building custom software, and we have reviewed a great many quotes issued by other firms. The largest differences are rarely in unit price. They sit in what a quote actually includes and what unit it is priced against. Below are six dimensions you can align line by line, plus a practical way to compress three quotes into one table.
1. First check whether the quote has units at all
Judging a software development quote starts not with the total but with whether it contains anything verifiable. A credible quote answers three questions: how many screens and feature points are being built, how many external interfaces are integrated, and how many person-days are being invested.
A quote consisting of a single line — "system development fee: 580,000" — cannot be compared with anything, because its boundary can stretch in either direction. It is 580,000 when you sign, and every item can later be reclassified as "not originally included" when the invoice grows.
2. Alignment item one: the granularity of the scope list
Put the three scope lists side by side and check whether each line is written at the same level of detail. Vendor A writes "membership module: registration, login, tiers, points, coupons". Vendor B writes "membership system (growth values, tier benefits, points mall, coupon packs, member days)". Similar word counts, three times the work.
The method: break every list down to the level of "one screen = one acceptable action", then merge them into a single master list. Wherever a list contains "etc.", "related functions" or "to be supplemented", require the vendor to complete it on the spot. Anything it cannot complete is treated as missing scope.
3. Alignment item two: screen count and interface count
Screen count is the most intuitive unit and the easiest to game. Counting only unique routed pages versus counting modals, state screens, empty states and error states can double the number for identical work. Standardize before comparing: count only pages with their own route, then list modals, form pages and admin list pages as separate line items.
Interface count matters just as much. WeChat Pay, SMS, maps, e-invoicing, an existing ERP — each one is independent work. A quote that says "third-party integration included" should be pressed on how many integrations and how overages are priced. For a mid-sized business system, five to eight external integrations is normal; an uncapped "integration included" line is exactly where later surcharges appear.
4. Alignment item three: staffing and person-days
Convert each quote into total person-days and divide by feature points to obtain a comparable productivity figure. A professional quote lists roles — product, design, frontend, backend, QA, project management — with headcount and days for each.
Some low quotes carry a lovely-looking effort table in which QA receives two days and project management receives zero. In custom software, QA typically accounts for 15 to 25 percent of cost and project management 8 to 15 percent. Cut those out and the cost does not disappear; it moves to rework and disputes after launch.
5. Alignment item four: timeline and payment milestones
Timeline and person-days constrain each other. A 300 person-day project promised in two months means either a team far larger than normal or an inflated effort table. Conversely, a cheap quote with an unusually long timeline usually means the team is running several projects and yours is queued behind them.
Align payment milestones stage by stage. The common structure is 30 percent on signing, 30 percent on prototype approval, 30 percent on development completion and 10 percent on acceptance. Anything demanding more than 50 percent upfront, or leaving under 5 percent as retention, requires corresponding delivery guarantees written into the contract.
6. Alignment item five: support scope and source code
"Source code delivered" needs unpacking: all of it, or a compiled build? Does it include the database schema, deployment scripts and third-party accounts? Does copyright transfer with delivery? A quote that leaves ownership vague saves money now and returns the entire bill at the second development phase, because the next vendor has to rebuild from scratch.
Support scope needs units too: is the free maintenance period three months or twelve, does it cover bug fixes or minor enhancements, and is response time four working hours or next business day? Different combinations of these three items are worth more than 10 percent of project value per year.
7. Compress the three quotes into one table
Build a six-row comparison table with the three vendors as columns and these rows: feature points, screen count, external interface count, total person-days by role, timeline and payment milestones, support and source scope. Only then add total price, and calculate two derived metrics: price per feature point and price per person-day.
If two vendors are close on price per feature point but far apart on total, the gap is scope. If scope matches but price per person-day differs by more than 30 percent, ask about team composition and location. These two metrics explain roughly 80 percent of quote variance; the remaining 20 percent is usually industry experience and reusable components.
8. When a low price is genuinely low
Cheap is not automatically a trap. Three situations justify it: the vendor has built something very similar and can genuinely reuse components and domain experience; your requirements are simple enough that standard features cover them; or the vendor is buying a reference case at a lower price — in which case lock the scope and acceptance criteria in the contract so nothing gets re-priced later.
The test is direct: ask the vendor to state which parts of your project are reused and which are built new. A vendor that can answer clearly has grounds for its price. A vendor that says only "we are efficient" is writing risk in the language of discount.
The goal of comparison is not to select the cheapest quote. It is to bring three quotes onto the same measuring scale so that price compares the same work. Only then does a software development quote become a real basis for a decision.