Let me state it from the conclusion. The true nature of a system-development estimate being "expensive/cheap" is mostly effort (person-months). Development cost is decided by "person-month unit price × number of people deployed × period," and about 80% of that cost is labor. And when estimates differ several-fold for the same requirements, most of that difference is in "whether non-functional requirements (performance, security, operations, maintenance) are included in the estimate." Is a cheap estimate truly cheap, or is "cost that bites later" just hidden — this article is a practical guide for buyers to come to spot that themselves.
This article is the cost installment of the complete guide to commissioning system development. For the whole commissioning decision, see that one.
1. The true nature of cost: everything reduces to "person-months"
Japanese system-development cost is, almost without exception, calculated in person-months.
開発費 ≒ 人月単価 × 投入人数 × 開発期間（月）
"3 engineers, at a unit price of 1M yen, for 4 months" is roughly 3 × 1M × 4 = 12M yen. This is the skeleton of an estimate. And — this is the most important part — about 80% of the development cost is labor. You're paying for people's time, not for server fees or license fees.
From this, three practical consequences follow.
- "Make it cheaper" is essentially "reduce the effort" — it becomes either cutting features or cutting quality.
- The difference in estimates is the difference in unit price or assumed effort — if it's double for the same requirements, one of the assumptions differs.
- "Add people and it'll finish faster" is wrong — the more people you add, the more coordination cost (Brooks's law). This is also why a small, fast team has the edge.
A guide to person-month unit prices
| Role/level | Person-month unit-price guide |
|---|---|
| Junior to mid-level engineer | 600k–1M yen |
| Senior, tech-lead class | 1M–1.6M yen |
| Big SIer/consultant (including multi-layered subcontracting) | 1.5M yen+ |
A big SIer being expensive isn't only a matter of technical skill. Due to the multi-layered subcontracting structure, each layer's margin rides on the unit price of the engineer who actually does the work. It's not rare that, of the 1.5M yen the buyer pays, less than half reaches the bottom-layer developer.
2. A guide to cost ranges by development type
Let's answer "so, how much does it actually cost." These are general market rates that vary greatly with requirements, but use them as a starting point for judgment.
| Development type | Cost-range guide | Period guide | Example |
|---|---|---|---|
| SaaS introduction/configuration | ~100k yen or so | Same day to a few weeks | Introducing/initial-setting off-the-shelf tools like accounting/attendance/CRM |
| Customization/small-scale development | 0.5–3M yen | 1–3 months | Extending an off-the-shelf product, a small internal business app, an LP/corporate site + simple features |
| Mid-scale business system | 3–10M yen | 3–6 months | Business systems like ordering/inventory/reservations, an MVP |
| Large-scale/scratch (B2B SaaS, etc.) | 10M yen–tens of millions | 6 months+ | Industry-specific B2B SaaS, a multi-tenant platform including payments |
The lumber-distribution B2B SaaS I worked on (which won the METI Minister's Award) is in the last category, on the scale of 221 API endpoints, 17 Terraform modules, 12 Lambdas, and 4 rounds of security audits. Compare amounts alone without knowing "what's included" and you'll misjudge. The next chapter is its core.
3. The "omissions" lurking in cheap estimates — the non-functional-requirement pitfall
The pattern where buyers lose the most is "I chose it because it was cheap, then it broke down in operations." Why does this happen? A cheap estimate usually omits the following non-functional requirements.
Non-functional requirements are not functional requirements like "build a screen" or "press a button and it saves," but requirements about the "quality" for the system to survive in production.
| Item often omitted | What happens if omitted |
|---|---|
| Performance | Slow and unusable as users grow. Rebuilt later |
| Security | Data leak, unauthorized access. Damages and loss of trust |
| Availability/resilience (DR) | Stops on failure, data is lost. Can't recover |
| Monitoring/observability | Can't notice failures. Can't find the cause |
| Testing/quality assurance | Bugs on every release. Too scary to touch for changes |
| Operations/maintenance | Build-and-done. Trouble handling and changes are extra cost |
These are not "nice-to-have" options but the premise of production operations. For example, if "idempotency (a mechanism that doesn't double-charge on retry)" isn't in the estimate for a system involving payments, that means you're cheaply buying "a system that will someday cause a double-charge incident."
The iron rule of reading estimates: when two estimates "differ by double for the same features," the cheaper one isn't superior — first suspect that the more expensive one includes non-functional requirements. To compare on the same footing, explicitly ask both companies "do you include performance, security, testing, monitoring, operations, and maintenance."
Operations/maintenance cost — the "invisible running cost"
Often overlooked, but a system isn't build-and-done. After production release, the operations/maintenance cost is generally around 15% of the initial development cost per year as a guide. For a system built for 10M yen, assume around 1.5M yen/year for maintenance. Choose by "the initial cost is cheap" without factoring this in, and it reverses on total cost of ownership (TCO).
4. Five checks to spot an estimate's validity
Look not at the size of the amount but at the "structure" of the estimate. A valid estimate satisfies the following five points.
Checklist
- Is the breakdown's granularity appropriate? — a rounded estimate like "development, all-inclusive, 8M yen" is a danger sign. Is the effort (person-days/person-months) broken down per requirement and process?
- Are assumptions and exclusions stated explicitly? — are "~ is separate" and "~ is not included" written? An ambiguous estimate is a breeding ground for later extra costs.
- Are non-functional requirements itemized? — do performance, security, testing, and operations exist as independent items?
- Are the requirements-definition and design processes included? — an estimate that starts straight from implementation pushes the ambiguity of requirements onto the buyer.
- Are the maintenance/operations conditions shown? — is the post-release scope, cost, and SLA written?
How to hold "uncertainty" — fixed price vs. quasi-mandate
Holding a fixed price (contract for work) while the requirements aren't fully fixed leads the development side to either estimate high by factoring in risk, or take it cheap and clash later. If requirements are fluid, a hybrid — start small with a quasi-mandate (time/effort-based) and switch to a contract for work for the parts that have firmed up — is healthy for both. "Everything at a fixed price, cheaply" is usually an illusion.
5. How one-person × generative AI changes the cost structure
In recent years, a development style like mine — one person (a small team) × generative AI — has become a realistic option on cost. Why can it be cheaper — let me honestly explain the basis.
| Reason it gets cheaper | Content |
|---|---|
| No middleman margin | No per-layer margins of the multi-layered subcontracting structure. The commissioned amount goes straight to development |
| Small coordination cost | Zero inter-company/inter-team coordination effort. Turn requirements fast in direct dialogue with the decision-maker |
| Faster implementation via generative AI | The speed of writing code rises, implementing more for the same effort |
| End-to-end | One person handles everything from requirements definition to infrastructure and operations, with no handoff loss |
But — and this is the most important — "cheap" must not be synonymous with "cut quality." Generative AI makes implementation fast, but it becomes production quality only after passing its output through verification gates that don't trust it as-is (type-safe boundary validation, automated tests, static analysis, security audit).
In my case, in the lumber-distribution DX I demonstrated 0 missing-authorization findings across all 221 endpoints via a third-party penetration test, and in the payments platform I ensure 0 double charges during production operation structurally via idempotency. "Fast and cheap, but safe because it's hardened by verification" — this is the divide of whether a one-person × generative-AI estimate is trustworthy. Conversely, a "cheap-only" counterpart who can't explain the verification gates is expensive in another sense.
FAQ
Q. How much is the market rate for system development?
It depends on the development type. SaaS introduction is up to ~100k yen, off-the-shelf customization or a small app is 0.5–3M yen, a mid-scale business system is 3–10M yen, and scratch development of a B2B SaaS including payments is 10M yen–tens of millions, as a guide. Cost is decided by "person-month unit price × number of people × period," and about 80% of the cost is labor, so it's essentially a matter of effort.
Q. Why do estimates differ several-fold by company for the same requirements?
There are two main causes. (1) The difference in unit price — a big SIer is more expensive because the multi-layered subcontracting margins ride on it. (2) The difference in assumed effort/premises — it varies greatly by whether non-functional requirements (performance, security, testing, operations) are included. Suspect that a cheap estimate may have omitted these.
Q. Is it OK to choose a cheap estimate?
Don't judge by amount alone. If the reason for the cheapness is "reducing middleman margins and coordination costs," it's healthy, but if it's the result of "cutting non-functional requirements or quality assurance," it'll break down in operations and reverse on total cost. It's important to confirm the estimate's breakdown, assumptions, and exclusions and compare on the same footing.
Q. How much should I budget for operations/maintenance?
A general guide is around 15% of the initial development cost per year. For a system built for 10M yen, around 1.5M yen/year. Judge by initial cost alone without factoring this in and it gets expensive on total cost of ownership (TCO). Confirm the maintenance scope, cost, and handling conditions at the estimate stage.
Q. My requirements aren't fixed yet. Can I still get an estimate?
You can get a rough estimate, but holding a fixed price is dangerous. While requirements are fluid, a hybrid — start small with a quasi-mandate (effort-based) and switch to a contract for work for the parts that firm up — is healthy. Choose a company that includes the requirements definition itself as the first process in the estimate.
Summary: look at the "structure," not the amount
To not lose out on system-development cost, here's what to grasp.
- Cost is decided by "person-month unit price × number of people × period," and 80% of the cost is labor — the difference in estimates is the difference in effort.
- The rough guide: SaaS introduction ~100k yen, customization 0.5–3M yen, scratch 3M yen–tens of millions — varies greatly with non-functional requirements.
- Cheap estimates tend to omit non-functional requirements (performance, security, testing, operations, maintenance) — compare on the same footing.
- Spot validity not by amount but by "the granularity of the breakdown" and "the explicit statement of assumptions and exclusions."
- The cheapness of one-person × generative AI is grounded in cutting middleman margins, and quality is ensured by verification gates — a different thing from "cheap-only."
If you're anxious about an estimate's validity, or want to confirm "is this amount appropriate" from a third-party perspective — I welcome such consultations too. From an inventory of requirements to structuring what costs how much, I organize it standing on the buyer's side.