The complete guide to commissioning system development: how to choose an outsourcing partner without failing, market rates, and in-house vs outsource from the decision-maker's view

Let me state the conclusion first. The biggest cause of failure in commissioning system development is not a lack of technical skill. It's "ambiguous requirements definition" and "naive estimation." What buyers should do first is not compare development companies, but (1) discern whether you truly need to build it (won't SaaS suffice), (2) understand the cost structure, and (3) reach a state where you can articulate and demand quality and security. With these three done, 80% of the commissioning's success or failure is decided.

This article provides a decision map for buyers (executives, business owners, IT staff) to not lose out, using as a "single source of truth" the design decisions of projects I actually worked on — an METI-Minister's-Award-winning B2B SaaS (lumber-industry DX), a payments platform that maintains 0 double charges during production operation, an enterprise AI platform for a major domestic broadcaster, and more. Each theme is detailed in a dedicated article, so read on from where you need.

A premise on numbers: the market rates in the text (person-month unit prices, development-cost ranges) are guides based on publicly available general survey/market information. Meanwhile, the quantitative values tied to my real projects (221 endpoints, 0 double charges in production, 4 rounds of self-conducted security audits, etc.) are measured values verifiable from the repository, and I don't assert business ROI (revenue, % effort reduction) since that requires the client's real data. The policy is to not fabricate.

1. Why does commissioning system development fail "half" the time?

Nikkei Computer's project survey (1 March 2018 issue) found that of 1,745 system introduction/replacement projects, 52.8% were "successes" and 47.2% were "failures." A success there had to satisfy three conditions: schedule, cost, and satisfaction.

Whether that third condition is included moves the number a great deal. In the same magazine's 16 October 2014 survey, where success was defined as "kept to the originally planned quality, budget and delivery date (QCD)," the success rate was 75%. Which is to say —

In roughly two out of ten projects, the deadline and the budget held, and the people who had to use the result were still unhappy.

That is the closest thing to the real shape of a failed commission. Nothing broke technically; what got built was not what was wanted — and most of that is decided before a line of code is written.

Let me narrow the root causes to three from my field experience.

All three can be greatly mitigated by the buyer's preparation. Conversely, no matter how much you compare development companies' technical skill, skipping this preparation leads to failure. Gartner finds that B2B buyers spend only 17% of their time meeting potential suppliers across a buying cycle — and when several vendors are in the running, any one of them gets a fraction of that. Building your decision criteria out of what you learn in sales meetings is not realistic on time alone, which is exactly why whether the buyer arrives with their own criteria divides the outcome.

2. The most important pre-commissioning judgment: before building, knock out the "option of not building"

The most expensive mistake is going out of your way to scratch-develop an operation that SaaS can cover. I believe the first job of a trustworthy development partner is to honestly advise "should this requirement be solved with off-the-shelf SaaS, or built."

The judgment can be made with a simple flow.

その機能は事業の差別化の核か？
├─ No  → まず SaaS / 既製品を探す（会計・勤怠・CRM・MA などは作らない）
└─ Yes → 既製品で要件を満たせるか？
          ├─ 満たせる → SaaS を採用し、足りない部分だけ連携・拡張する
          └─ 満たせない（業界特有の複雑な商流・独自の業務制約）→ スクラッチ／ハイブリッド

The lumber-industry DX I worked on was the archetype of the latter. The multi-stage commercial flow of "forestry → market → sawmill → precut → builder → manufacturer," permissions that differ by industry role, cross-company transactions, and tenant separation — these can't be expressed by off-the-shelf groupware or e-commerce, so scratch was justified. On the other hand, it takes a hybrid strategy: using off-the-shelf foundations to the maximum — AWS Cognito for auth, Stripe Connect for payments — and limiting what's built in-house to 'industry-specific logic only.'

This "in-house vs outsource" and "SaaS vs scratch" decision most greatly affects the commissioning's success or failure. The decision framework is detailed in a separate article.

3. Cost structure and market rate: an estimate is decided by "person-months"

What buyers feel most anxious about is cost. Japanese system-development cost is, almost without exception, decided by person-months.

開発費 ≒ 人月単価 × 投入人数 × 期間（月）

And about 80% of that cost is labor. So "expensive/cheap" is essentially the question of "how many people, for how many months, at what unit price." A guide to person-month unit prices is roughly as follows.

A guide to total-amount ranges by development scale is as follows (general market rates that vary greatly with requirements).

The key to spotting an estimate is not the size of the amount but the "breakdown" and "the presence of non-functional requirements." A cheap estimate usually omits the following.

• Non-functional requirements: performance, availability, security, monitoring/operations, disaster recovery (DR)
• Quality assurance: tests, code review, security audit
• Operations/maintenance: post-release maintenance cost (a guide of around 15% of the development cost per year)

The failure "the initial estimate was cheap, but it broke down in operation" is mostly missing these. How to read estimates and cost optimization are detailed in a dedicated article.

4. How to choose an outsourcing partner: discern by "technical skill × track record"

When Japanese B2B buyers choose a development company, they prioritize technical skill and track record. Before lining up companies on an aggregator (Hatchu-navi, Aimitsu, etc.), first get clear on what each type of vendor puts at risk, then evaluate the counterpart with the checklist further down.

There are five kinds of vendor — and each carries a different risk

Where to commission the work is not a question of better or worse; it is a choice about which risks sit with whom. It is not as simple as "the bigger the company, the safer" or "an individual is risky."

I am the last row of that table myself — an individual — and I have also taken work through crowdsourcing. That is exactly why I want to be candid about the risks of hiring an individual.

Hiring a freelancer directly: the risks, and how to close them off in the contract and in the setup

"Freelancers vanish." "They hold the code hostage." "In the end, they hand the business decisions back to you." Every one of these worries about hiring individuals can actually happen. Most of them, though, can be prevented structurally through the contract and through whose name things are in (handing the whole job over is covered in Chapter 6).

One more point is a legal obligation. A business that commissions work from an individual who uses no employees (among others) must, immediately upon commissioning, state the content of the work, the amount of remuneration, the payment date, and other terms in writing or by electronic means (Japan's Freelance Act, Articles 2 and 3). The law exists to protect the contractor, but putting the terms in writing also protects the buyer from "he said, she said."

Outsourcing-partner evaluation checklist

• Do they have published concrete track records (can they explain the project's scale, tech stack, and results)
• Can they propose not building (can they honestly say where SaaS suffices? Answering "we can build it" to everything is a danger sign)
• Do they ask about non-functional requirements themselves (do they nail down performance, security, operations, DR in requirements definition)
• Can they articulate quality gates (the specifics of tests, type safety, CI/CD, security audit)
• Do they take responsibility through operations/maintenance (is it build-and-done)
• Is the estimate's breakdown transparent (the basis for person-months, the cost of non-functional requirements)

Answering the natural anxiety of "one-person × generative AI, is it OK?"

In recent years, commissioning to developers like me who leverage one-person (small-team) × generative AI has increased. While "fast and cheap," what buyers naturally hold is the anxiety of "is quality OK with one person" and "won't it become person-dependent." This is a correct question.

My answer is that what makes it "fast and cheap" is generative AI, but what ensures 'safety' is human verification gates. Generative AI raises the speed of writing code, but it becomes production quality only by passing its output through a multi-layered mechanism that doesn't trust it as-is — validation at type-safe boundaries, automated tests, static analysis, security scanning, and penetration testing.

This isn't abstraction. In the lumber-industry DX, through four rounds of self-conducted security audits including a penetration test across 15 real roles, I demonstrated 0 missing-authorization findings across all 221 endpoints. In the payments platform — a team of three core developers, where I led the reliability layer — the code structure of idempotency and atomic transactions keeps double charges at 0 during production operation. Not "fast because AI wrote it," but "safe even when built fast, because it's hardened by verification" — this is the basis of quality to present to buyers.

The other worry, person-dependence (things stop when that person is gone), is a separate problem from quality, and verification gates don't prevent it. What prevents it is how ownership and deliverables are designed; the concrete items are in the checklist in Chapter 7. How I handle ownership and deliverables when I take a project on as an outside technical lead is set out on the fractional CTO page.

5. Requirements definition that doesn't fail, and "staged introduction"

Since ambiguous requirements definition is the biggest failure factor, you should pour the most energy here. That said, no buyer can write perfect requirements from the start. What matters is to "not do a full migration all at once."

When systematizing legacy operations (phone, fax, Excel), I recommend the following staged introduction.

Phase 1（1〜3ヶ月）: 情報共有・可視化のみ（既存のExcel併用OK）
   ↓  現場が「これは便利だ」と実感する
Phase 2（4〜6ヶ月）: 一部業務（発注など）を移行（Excel併用）
   ↓  併存させ、移行リスクを下げる
Phase 3（7〜12ヶ月）: 全面移行（旧フローを段階的に廃止）

Do a full migration all at once and the field gets confused, becoming an "unused system." Set a coexistence period to build up the field's acceptance — this divides success or failure, especially in legacy-industry DX. In the lumber DX too, I built a path to upload existing Excel as-is and turn it into a DB, designing it so the field could migrate without discarding the tools they were used to. How to start legacy-operation DX — the signs that Excel has hit its limits, choosing what to migrate to, and digitizing fax orders in stages — is detailed in when Excel hits its limits: how to move off spreadsheets.

6. Don't hand the whole job over: what the buyer must keep, even when outsourcing

"I don't understand the technical side, so I'll leave everything to you." A commission that starts with that sentence often ends in "this isn't what I had in mind." However capable the vendor is, they cannot make your business decisions for you. When work proceeds without the inputs for those decisions, the vendor has no choice but to fill the gaps with guesses — and every wrong guess becomes rework.

Delegating the technology and delegating the decisions are two different things. Here is where the line falls.

The acceptance criteria matter most. The moment the buyer lets go of them, you get a structure where the vendor passes their own work against a standard they set themselves. Put the criteria into words before you order, and have the vendor write the tests that show those criteria are met. With that division of roles, the buyer keeps control of acceptance even without understanding the technology.

In practice, three decisions made up front prevent it.

1. Name a single decision-maker — with several points of contact, the vendor can't tell whose instruction is final.
2. Make deciding a regular meeting — once a week, in a short meeting the decision-maker attends, settle priorities and open questions. The trick is to have the vendor prepare not the technical details but "what we need to decide this week."
3. Write down what was decided — keep decisions in meeting notes or the issue tracker. It prevents "he said, she said," and it lets the reasoning survive a change of people.

Handing everything over happens on the vendor's side too (building exactly what was said without trying to understand the business). The failure patterns that include this two-way version, and how to spot a partner who won't cause them, are covered in detail in how to choose a development company that won't fail you.

7. A checklist of what the buyer should own from day one of the contract

Whichever type of vendor you choose, if the following are in the buyer's name and hands from the first day of the contract, your business keeps running even if the vendor falls ill or the relationship ends. Conversely, anything left in the vendor's name can become a "hostage" in a negotiation. Go through this list alongside the contract review.

• The source-code repository lives in your own GitHub organization, with the vendor joining as an outside collaborator
• The cloud accounts (AWS, Google Cloud, etc.) are in your company's name and billed to you; the vendor gets only the permissions the work requires
• The domain and DNS registrant and management account are in your company's name
• The infrastructure is codified as IaC (Terraform or similar), so another engineer can rebuild the same environment
• There is a runbook: deploying, rolling back, first response to an incident, restoring from backup
• There is an environment-variable list: which setting is used for what and where it is stored (a list of names, purposes, and storage locations — not the secrets themselves)
• The main business flows have automated tests and CI, so every change is verified automatically
• Your company owns the admin rights (production database, payment service, email delivery, each SaaS admin console, etc.), and the vendor gets an individual account (no shared accounts)
• The copyright clause states that copyright in the deliverables is assigned to the buyer. Unless the assignment clause names the rights in Articles 27 and 28 of the Copyright Act (adaptation rights and the like), those rights are presumed to stay with the assignor (Copyright Act, Article 61(2))
• The period of non-conformity liability (for contract-for-work): how long after acceptance defects will be fixed free of charge. The Civil Code's default is "give notice within one year of learning of the non-conformity" (Article 637), but in practice contracts usually set "○ months after acceptance"

Of these, the hardest to recover later is whose name the repository, cloud, and domain are in. If they are first created in the vendor's name, moving them requires the vendor's cooperation. If they are in your name from the start, ending the contract is just a matter of revoking the vendor's access. Copyright and non-conformity liability under each contract type are explained in detail in contract-for-work, quasi-mandate, or lab-type: choosing a system-development contract.

How I work: on the engagements I take, the repository and cloud accounts are created in the client's name from day one, and I work with collaborator permissions. When the contract ends, you simply remove my access. As a rule, copyright in the deliverables is assigned to the client (how generic, reusable library or template parts are handled is stated in the individual contract). A README, an architecture diagram, an environment-variable list, and a runbook are standard deliverables at no extra cost; the infrastructure is managed as IaC such as Terraform, and automated tests for the main flows plus CI are delivered as standard. On fixed-scope (contract-for-work) engagements, defects found within 3 months after acceptance are fixed free of charge (non-conformity liability; the period and other terms can be adjusted per contract).

8. Discerning quality and security: the "four structures" buyers should demand

The difference between "something that works" and "a system that withstands production operations and a third party's attacks and audits" isn't visible from the outside. Buyers should demand whether the following four are held as a mechanism (structure). These are also the differentiator I consistently build in across all projects.

For example, in payments, you guarantee correctness with the code structure of "recompute the amount server-side," "prevent double execution with an idempotency key," and "deduplicate webhooks with conditional writes." Rely on operational carefulness and an incident will eventually happen. A concrete checklist for commissioning payment/billing systems is summarized in a dedicated article.

9. "One-person × generative AI" as a commissioning option

Finally, on the commissioning structure. Traditionally it was "commission a big SIer at scale" or "commission a contracting firm holding a multi-person team." To that, a third option has become realistic: one person (a small team) × generative AI handling everything from requirements definition through infrastructure, security, and operations one-stop.

This option suits cases like the following.

• New ventures, MVPs, and business systems where speed and cost matter
• Wanting to turn requirements quickly in direct dialogue with the decision-maker
• Wanting to delegate it full-stack end-to-end and cut inter-company coordination cost

Conversely, projects premised on ultra-large scale and coordination among many stakeholders suit a big organization's structure. "Fast and cheap" and "a large-scale structure" are a trade-off, and a counterpart who can say so honestly is exactly the one you can trust.

A proposal to buyers: I handle requirements definition, design, frontend, backend, infrastructure (AWS/GCP/Terraform), security, and operations alone end-to-end, and ensure that quality with the verification gates of "type safety, tests, security audit, idempotency." An METI-Minister's-Award-winning B2B SaaS (every stage handled alone), a payments platform with 0 double charges in production (a team effort, where I led the reliability layer), an AI video platform that took first place in CrowdWorks' weekly contract ranking (handled alone) — the setups differ, but all are products of the same policy: "build fast, but harden with verification."

Summary: 80% of the commissioning's success is decided "before writing code"

To not lose out on commissioning system development, here are the seven points buyers should grasp.

1. The true cause of failure isn't technical skill but ambiguous requirements definition and naive estimation — crush these first.
2. Before building, always knock out the "option of not building (SaaS)" — limit scratch to the core of differentiation.
3. Cost is decided by person-months, and 80% of the cost is labor — look at the "breakdown and non-functional requirements" rather than the amount.
4. Choose the outsourcing partner by "technical skill × track record," and choose one you can demand quality gates of. The vendor types — SIer, development firm, via a matching site, crowdsourcing, an individual — differ in the risks they carry, not in rank.
5. Don't hand the whole job over — delegate the technology, but keep the priorities and the acceptance criteria.
6. Put the repository, cloud, and domain in your name from day one — with a runbook, an environment-variable list, IaC, and automated tests in place, anyone can take over.
7. One-person × generative AI is valuable not just for "fast and cheap" but by ensuring "safety" with verification gates.

I take on legacy-industry DX, new development/rebuilding of B2B SaaS, payment/billing platforms, and business adoption of generative AI — from requirements definition through infrastructure, security, and operations, one-stop at this level. If you're considering commissioning, let's first organize the current issues and "should you build it or not" together.