# How to compare competitive quotes for system development — judging by price alone will fail you

> A practical guide to not losing out when gathering competitive quotes for system development. From a buyer's perspective, it explains how to read a quote's breakdown (person-months, non-functional, maintenance), the danger signals of a quote that's too cheap, and how to compare correctly on identical requirements. It systematizes—drawing on real-project experience—the multi-axis scoring that lets you look at price last, plus the anti-patterns of competitive bidding.

- Published: 2026-07-07
- Author: 友田 陽大
- Tags: 受託開発, システム開発, 発注, コスト最適化, 技術選定, B2B SaaS
- URL: https://tomodahinata.com/en/blog/system-development-quotation-comparison-guide
- Category: Procurement, in-house & cost
- Pillar guide: https://tomodahinata.com/en/blog/system-development-outsourcing-guide-vendor-selection-cost

## Key points

- Competitive bidding is not 'the task of choosing the cheapest' but 'the task of putting every vendor on the same footing.' Price is the axis you must not compare first—you look at it last.
- Unless you first nail down the RFP, requirements, and expected non-functional levels and hand every vendor the same materials, each is looking at different assumptions and the comparison never holds.
- Break the quote's breakdown into three layers—functional (person-months) / non-functional (performance, security, testing, monitoring) / operations and maintenance—and re-sort them, and the differences become visible.
- A quote that's too cheap is really a set of 'omissions' in requirements definition, non-functional, maintenance, and testing. Ten danger signals let you screen it out mechanically.
- The final decision is a multi-axis scoring of technical capability, requirements understanding, transparency, maintenance structure, and price. Choose neither the cheapest nor the most expensive, but 'the vendor whose breakdown is clear and reasonable.'

---

Let me start with the conclusion. **Gathering competitive quotes is not "the task of choosing the cheapest company." It is "the task of putting every vendor on the same footing."** And within that comparison, price is **the axis you must not look at first** and **the axis you look at last.** Why? Because when you line up several vendors' quotes, the biggest reason the prices differ is not "a gap in ability" but that **the requirements each vendor is looking at, and the scope each folded into its quote, were fundamentally different to begin with.** You line up apples and oranges, pick "the oranges are cheaper," and never notice—this is the structure of failure in competitive bidding.

This article is a practical guide for buyers (owners, business leads, IT-systems staff) to read the breakdown (person-months, non-functional, maintenance), screen out the danger signals, and **compare correctly on identical requirements** without being swayed by price. The going market rates themselves are left to [the market rates and quote breakdown for system development](/blog/system-development-cost-estimate-market-rate-guide), and the overall procurement decision to [the complete guide to procuring system development](/blog/system-development-outsourcing-guide-vendor-selection-cost); here we concentrate on "how to compare multiple quotes."

> **A note on the numbers**: the market rates in this article (per-person-month rates, maintenance-fee percentages, etc.) are publicly available general benchmarks. The quantitative values tied to my real projects (221 endpoints, four rounds of security audits, zero double-charges in production, etc.) are measured figures verifiable from the repository; business ROI requires the client's real data, so I make no definitive claims about it.

---

## 1. The structure of how competitive bidding fails — "price" is the axis you should least compare

Suppose you gather competitive quotes from three vendors and get Vendor A at 8 million yen, Vendor B at 12 million yen, and Vendor C at 16 million yen. Most buyers think here, "A is cheap, C is expensive." This is the first mistake.

Break down the reasons the prices differ, and it comes down to almost one of the following.

| Reason the price differs | The reality |
|---|---|
| **Difference in scope** | A is looking at "just the main screens," while C is looking all the way through "admin screens, reports, and permissions" |
| **Presence or absence of non-functional requirements** | The cheaper side has not included performance, security, testing, or monitoring in its quote |
| **Presence or absence of a requirements-definition phase** | A skips requirements definition and pushes the ambiguity onto the buyer |
| **How maintenance and operations are handled** | A is "build it and done," while C includes post-release maintenance |
| **Difference in per-person-month rate** | Whether margins from a layered-subcontracting structure are baked in |

In other words, **most of the price gap is not "a gap in quality" but "a gap in scope and assumptions."** Compare prices in this state and all you do is pick "the quote with the narrowest scope that omitted the non-functional" as the cheapest—which can amount to the same thing as **choosing "the most dangerous quote."**

So the first thing a buyer should do is not compare quotes. It is **to build a footing on which every vendor can quote on "the same requirements, the same scope."** Once the footing is level, price almost automatically turns into "a meaningful axis of comparison."

---

## 2. Compare on identical requirements — nail down the "footing" first

The key to making the comparison hold lies **before** you gather the quotes: you standardize the request you send to each vendor.

### 2-1. Hand every vendor the same materials

If you convey "a system roughly like this" to each vendor piecemeal, verbally or by email, each decides the scope by its own interpretation. This is the root cause that breaks the comparison. At a minimum, hand every vendor the following as **identical documents**.

- **RFP (Request for Proposal)**—background, objectives, scope, constraints, schedule, evaluation criteria
- **Requirements definition (or a draft of it)**—a list of the features you want built and their priorities
- **Expected non-functional levels**—how far you require performance, availability, security, and operations to go

The third, "expected non-functional levels," is the part a buyer finds hardest to put into words. What helps here is the [Non-Functional Requirements Grades](https://www.ipa.go.jp/archive/digital/iot-en-ci/jyouryuu/hikinou/index.html) published by IPA. Because it itemizes non-functional aspects such as availability, performance, extensibility, operability/maintainability, and security and lets you indicate the required level in tiers, it **structurally resolves the problem of "the buyer being unable to articulate the non-functional."** Simply attaching it means non-functional line items start appearing in every vendor's quote, and the resolution of your comparison jumps.

### 2-2. Specify a "format" when you request the quote

If each vendor submits in a free-form format, the granularity and the line items are all different and cannot be re-sorted. At the request stage, specify that the following items **must be included in the breakdown**.

| Item to specify | Purpose |
|---|---|
| **Scope (in / out)** | Align the scope assumptions across vendors |
| **Effort per phase (person-days, person-months)** | Ban "all-in" and align the granularity |
| **Non-functional requirement items and effort** | Put performance, security, testing, and monitoring on their own lines |
| **Assumptions and exclusions** | Force "X is separate" into writing and prevent later add-on costs |
| **Scope, cost, and SLA of operations and maintenance** | Make the running cost comparable |
| **Key risks and response approach** | Make each vendor's risk sensitivity visible |

This format specification is exactly what separates success from failure in competitive bidding. **Only once you make them pour into the same vessel does the difference in contents become visible.**

---

## 3. How to read a quote's breakdown — decompose it into three layers

Once every vendor's quote is in, before the price, **decompose the breakdown into three layers** and re-sort.

```text
レイヤー1  機能開発      … 画面・API・帳票など「動くもの」を作る工数
レイヤー2  非機能        … 性能・セキュリティ・テスト・監視・可用性
レイヤー3  運用・保守    … リリース後のランニング（障害対応・改修・SLA）
```

Most buyers compare prices looking only at Layer 1. But **the landmines you step on after you order are Layers 2 and 3.** A quote that is thin (or blank) here is not cheap—it merely has "costs hidden that will bite you later."

### Comparison template

"Translate" every vendor into this structure and line them up. For a company that came in with "development, all-in," ask for resubmission in this form.

| Breakdown | Vendor A | Vendor B | Vendor C |
|---|---|---|---|
| Layer 1: functional development (person-months) | 6 person-months | 7 person-months | 8 person-months |
| Layer 2: non-functional (performance, security, testing, monitoring) | Not stated | 2 person-months | 3 person-months |
| Layer 3: operations and maintenance (annual) | Not stated | ~15% of the initial build | ~15% of the initial build + SLA |
| Requirements-definition phase | Not included | Included | Included |
| Assumptions/exclusions stated explicitly | No | Yes | Yes |

Re-sorted this way, you see at a glance that it is not "A is cheap" but "A is not looking at non-functional, maintenance, or requirements definition." You can correctly understand that **choosing A = the decision to re-buy Layers 2 and 3 later as add-on costs.**

### How much of the effort the non-functional takes up (a real example)

If you think "the non-functional is just noise," let me show you the actual scale. The lumber-distribution B2B SaaS I built (which won the Minister of Economy, Trade and Industry Award) was composed of **221 API endpoints, 17 Terraform modules, 12 Lambdas, and four rounds of security audits.** Of these, the effort for "making the screens work" was only a small part; the bulk was spent on the non-functional—**authentication, authorization (multi-tenant data isolation), availability, monitoring, and security.** Third-party penetration testing demonstrated **zero authentication gaps** across all 221 endpoints, and this "zero" is the result of allocating effort to the non-functional. A quote that omits the non-functional is omitting this entire foundation.

---

## 4. Danger signals of a quote that's too cheap — 10 red flags

A quote whose price is far and away the cheapest—the iron rule is to **doubt it before you welcome it.** If even one of the following applies, choosing it as is is dangerous. Use it as a mechanical checklist.

- [ ] **Rounded up into "development, all-in," with no effort breakdown**—the basis cannot be verified
- [ ] **No requirements-definition or design phase exists in the quote**—you pay the debt of ambiguity later
- [ ] **Not a single line for non-functional requirements (performance, security, monitoring)**—it breaks down in production
- [ ] **Testing effort is extremely low, or zero**—bugs surface with every release
- [ ] **No mention of operations or maintenance**—"build it and done," with incident response and fixes billed separately
- [ ] **Assumptions and exclusions are not written down**—a breeding ground for add-on costs
- [ ] **The timeline is unnaturally short compared with other vendors**—either quality is cut, or it slips later and becomes a dispute
- [ ] **No mention whatsoever of the key risks**—not looking at risk = not seeing it
- [ ] **Answers to your questions are vague or deferred**—kindling for trouble after the quote
- [ ] **Presents the price first and says the breakdown comes "after the contract"**—the most dangerous sign of all

Be especially careful with **systems that handle payments or personal data.** For example, if the design for "idempotency (a mechanism that does not double-charge even on retry)" is not included in a payment quote, that means you are **cheaply buying "a system that will someday cause a double-charge incident."** The payment platform I operate maintains **zero double-charges in production**, and this is the result of weaving the idempotency structure into the design effort in advance—not the sort of thing you can bolt on later. Whether this kind of foundation is missing behind the low price—reading that out of the breakdown is the essence of the danger-signal check.

---

## 5. Look at price last — multi-axis scoring

Once you have aligned the breakdowns and screened out the danger signals, at last comes the final comparison. Here too, rather than choosing "the cheapest," you **weight several axes and score them.**

| Evaluation axis | Weight (example) | What to look at |
|---|---|---|
| **Technical capability / track record** | 25% | Comparable production track record, shareable deliverables, soundness of the technology stack |
| **Depth of requirements understanding** | 20% | Whether they can restate your problem in their own words, the quality of their probing questions |
| **Transparency of the quote** | 20% | Granularity of the breakdown, explicit statement of assumptions/exclusions, presence of any "all-in" |
| **Coverage of non-functional and quality** | 15% | Whether performance, security, testing, and monitoring are independent line items |
| **Maintenance and operations structure** | 10% | Post-release scope, SLA, communication arrangements |
| **Price** | 10% | Whether it is within a reasonable range (checked against external benchmarks) |

Note that price carries a weight of **just 10%.** What you should protect in competitive bidding is not "choosing the cheapest" but "**choosing the vendor who, within a reasonable range, has a clear breakdown, includes the non-functional and maintenance, and correctly understands the requirements.**" Neither the cheapest nor the most expensive—in most cases the right answer is **the quote whose structure you can trust.**

### Verify the reasonableness of person-months and effort against external benchmarks

"Is this person-month figure even reasonable to begin with?"—that is hard for a buyer to judge alone. Here, IPA's [Software Development Analysis Data Collection](https://www.ipa.go.jp/digital/software-survey/metrics/index.html) helps. From a large number of real projects, quantitative data on effort, duration, scale, productivity, and reliability is published, letting you **check the reasonableness of a quote against an external benchmark.** If "A's effort is half the going rate," you can form the hypothesis that it is not cheap but that something is missing.

---

## 6. Anti-patterns of competitive bidding — four things you must not do

Finally, here are the classic ways to make competitive bidding **backfire.**

### 6-1. Wielding the cheapest quote as material for haggling

"A quoted 8 million yen. Can't you do it for the same?"—this may work in the short term, but in practice it gives the vendor **the incentive to "cut quality to make the numbers add up."** What gets cut is the invisible non-functional and testing. Understand that competitive bidding is not a haggling tool but **a tool for aligning scope and quality on identical requirements.**

### 6-2. Using competitive bids as "a substitute for requirements definition"

Throwing it out to each vendor before the requirements are fixed and deciding the requirements from a patchwork of the proposals that come back—this is backwards. Ambiguous requirements produce different assumptions at each vendor and break the comparison. **Ordering requirements definition itself as the first phase** (starting small on a quasi-delegation basis) is, in the end, faster and safer.

### 6-3. Using too many vendors / too few

With one vendor you have no sense of the going rate and cannot verify reasonableness. But spread it across five or more and the buyer is worn down by explaining to each vendor and reading through the quotes, and the quality of comparison drops. **Around three** is the realistic landing point.

### 6-4. Misreading a "solo developer × generative AI" quote by the same yardstick

In recent years, a quote from a **solo developer (or a small team) × generative AI**, like mine, sometimes enters the comparison set. This quote looks cheap because **there are no middleman margins or coordination costs and the order amount goes straight into development**—not because quality is being cut (detailed in the [market-rates article](/blog/system-development-cost-estimate-market-rate-guide)). Conversely, **whether they can explain their verification gates (type-safe boundary validation, automated tests, static analysis, security audits)** is the dividing line for whether that low price is healthy. In my case, measured figures such as zero authentication gaps in the lumber DX, zero double-charges in the payment platform, and 100% test coverage are the assurance. If you include a solo-developer × AI option in your competitive bids, verify the basis for "why it is cheap" through the breakdown and the verification process.

---

## Summary: level the footing, read the breakdown, and price comes last

Let me organize once more the order for not losing out in competitive bidding.

1. **Do not compare price first**—most of the gap is not ability but "a difference in scope and assumptions."
2. **Level the footing first**—hand every vendor identical RFP, requirements definition, and expected non-functional levels.
3. **Decompose the breakdown into three layers**—re-sort by functional (person-months) / non-functional / operations and maintenance.
4. **Screen out the danger signals mechanically**—watch for all-in pricing, zero non-functional lines, no maintenance stated, and too little testing.
5. **Price last, choose on multiple axes**—within a reasonable range, choose the vendor whose breakdown is clear.

If you cannot fully read a competitive quote's breakdown, or want to confirm "is this price reasonable?" with a third party's eyes—such consultations are welcome too. From taking stock of the requirements, to translating each vendor's quote onto the same footing, to structuring what costs how much, I organize it standing on the buyer's side.