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.
Want a sense of the cost?
Fixed-quote, staged-ordering pricing is public
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. Checking the "market rate" yourself — against published data
Almost every cost range in circulation, including the table above, is a guide with no source behind it. Guides are a fine starting point, but they cannot tell you whether your estimate is reasonable. Only data with a stated population and sample size can do that.
Two such datasets exist for Japan.
3-1. IPA's measured figures — how big a "normal" project is
Japan's Information-technology Promotion Agency (IPA) collects and publishes quantitative data on real development projects. Two medians from the latest edition, Software Development Analysis Data 2022:
| Metric | Median | Sample |
|---|---|---|
| Project effort | 7,395 person-hours | N=1,444 |
| Project duration | 10.1 months | N=1,396 |
Divide 7,395 person-hours by 160 hours a month and you get roughly 46 person-months — about 46M yen at a 1M yen unit price. That is an order of magnitude away from the common "3–10M yen for a mid-sized business system" guide.
The gap is not an error; it is a difference in population. IPA's data comes mainly from enterprise projects run by large system integrators, and is not representative of small-business work. Which is precisely how to use it:
Ask what fraction of IPA's median your project is.
A 30-person-month estimate is about two-thirds of the median. A 10-month schedule is exactly the median. Whether the order of magnitude is right is answerable this way — and so is the reverse: an estimate to build a core business system in 3 person-months is one-fifteenth of the median, which tells you something immediately.
The same publication carries one more figure worth knowing before you commission anything:
b: modification/maintenance, 761, 51.5% ／ a: new development, 430, 29.1% New development is just under 30%, modification/maintenance is just over 50%, and together they account for nearly 80%. […] From 2016–2021, new development fell from 32.5% to 29.1% and modification/maintenance rose from 45.8% to 51.5%.
— IPA, Software Development Analysis Data 2022 (by project count, N=1,479)
More than half of the measured work is not new development but maintenance of systems already running. That is a share of project counts, not of spend — but "build it and you're done" is the minority case, and knowing that changes how you read an estimate. Post-launch running and maintenance cost is the larger half of the bill, so an estimate that stops at launch is not an estimate of the system.
3-2. JUAS's measured figures — how much a company like yours spends at all
There is a second angle. The Japan Users Association of Information Systems (JUAS) publishes IT budget as a percentage of revenue in its Corporate IT Trends Survey 2026 (FY2025 survey, 957 valid responses).
Looking at the IT budget ratio overall, the FY2025 trimmed mean was 1.47%, up 0.07 points.
— JUAS, Corporate IT Trends Survey 2026 (n=703; trimmed mean = calculated on the middle 80% after removing the top and bottom 10%)
For a company with 1B yen in revenue, that puts the IT budget around 15M yen a year. Does a single year's development cost vastly exceed that annual budget? This is not a check on "expensive vs. cheap" but on whether the spend fits the company's capacity. If it does not, that is your argument for splitting the work into phases.
Note that respondents are listed companies and their peers, not small businesses. Borrow the way of thinking about the ratio, not the absolute number.
3-3. Putting the three checks in order
So when an estimate arrives:
- Is the order of magnitude right? — what fraction of IPA's median (≈46 person-months / 10.1 months) are the quoted person-months and schedule?
- Does it fit your capacity? — is the annual total sane against a ~1.5%-of-revenue ratio?
- Can you read the breakdown? — the "omissions" check in the next section.
Checks 1 and 2 take five minutes. And in practice, an estimate that fails those two is worth renegotiating from its premises rather than reading line by line.
4. 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).
5. 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.
6. 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 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.
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.