Let me give the conclusion first. The cause of a failed system-development project is not the technical difficulty that surfaces after work begins. Almost without exception, it converges on four structural flaws you should have been able to spot before signing: blind hand-off, multi-tier subcontracting, broken communication, and neglected technical debt. So choosing a development company that won't fail you is not about "searching for a good company" but about reasoning backward to check "whether this partner will avoid these four patterns of collapse." And each pattern maps to a clear selection criterion for preventing it. This article is the map for that backward reasoning.
This article is a practical guide for buyers (executives, business owners, and IT/information-systems staff) to avoid collapse, taking as its "single source of truth" the quality mechanisms I've built into projects I have actually delivered — a METI Minister's Award-winning B2B SaaS (DX for the lumber-distribution industry), a payment platform that maintains zero double-charges in production, an enterprise AI platform for a major domestic broadcaster, and more. The full picture is compiled in the complete guide to commissioning system development; this article is its "selection chapter, reasoning backward from the patterns of collapse."
On the numbers: The quantitative figures tied to my real projects (221 endpoints, zero production double-charges, four rounds of security audits across 15 real roles, 100% test coverage, and so on) are actual measurements verifiable from the repositories. Business ROI (revenue or percentage reduction in labor), on the other hand, I do not assert, because it requires the client's real data. The policy is: no fabrication.
1. Why "choosing a partner who won't collapse" is more reliable than "searching for a good company"
The success rate of system-development projects has long been said in the industry to be "about half." Surveys repeatedly report that only around half of projects keep to their original QCD (quality, cost, delivery). What matters is the fact that much of that failure is decided "before a line of code is written," in the structure of the team and the contract.
In other words, collapse is not a matter of luck or of variance in technical skill, but a reproducible pattern. If so, the buyer's strategy becomes clear. Rather than comparing countless development companies side by side to find "one that looks good," it is far more reliable to reason backward and rule out whether the partner carries the four structures that produce collapse.
Let me first list the four patterns and the selection criteria reasoned backward from them. Each chapter of this article digs into one row of this table.
| Pattern of collapse | Typical symptoms | Root cause | Selection criterion reasoned backward |
|---|---|---|---|
| ① Blind hand-off | A finished product "not what I imagined"; a system nobody uses | Both buyer and vendor push responsibility onto the other, and requirements diverge from the actual work | Whether they propose not building, and turn non-functional requirements back to you as questions |
| ② Multi-tier subcontracting | Variable quality, passing-the-buck on liability, extra charges | The prime contractor pushes implementation many tiers down, and intermediary margins erode the quality budget | Whether they can disclose how many tiers down the implementer sits / whether you can pin down subcontracting in the contract |
| ③ Broken communication | Misaligned understanding of the spec, inability to review, rework | Layers of a telephone game sit between the decision-maker and the implementer | Whether you can talk directly and frequently with the person who actually implements |
| ④ Neglected technical debt | Unable to modify after delivery, ballooning maintenance costs, legacy decay | No tests, types, or documentation, so it breaks every time you change it | Whether they can speak to quality gates like testing, type safety, CI, and security audits |
From here, we'll reason backward through these four rows in order.
2. Pattern ① "Blind hand-off" — a partner who will take on responsibility
Symptoms and root cause
Blind hand-off runs in both directions. Hand-off on the buyer's side is bowing out of requirements definition with "you're the pro, just build something good." Hand-off on the vendor's side is building exactly as told without trying to understand the business, then pushing back with "it's as specified." When these two mesh, you end up with a system that works but nobody uses.
As the DX White Paper points out repeatedly, the biggest reason DX stalls at "digitization" and never reaches "transformation" is not technology but the gap between the business and the builder. Blind hand-off institutionally manufactures that gap.
The selection criterion reasoned backward: can they "propose not building" and "turn questions back to you"?
A partner who won't cause blind hand-off tries to involve the buyer as a party to requirements definition. There are two ways to tell.
- Can they propose not building? A partner who answers "we can build it" to everything is dangerous. An excellent developer can propose reducing your own spend: "an off-the-shelf SaaS covers that requirement; the only part worth building is this." This "build or don't build" judgment is the starting point for avoiding collapse, and I explain it in detail in the decision framework for in-house vs. outsource and SaaS vs. from-scratch.
- Do they turn non-functional requirements back to you as questions? "How many concurrent users should performance assume?", "In a failure, how much downtime is acceptable?", "Do you need audit logs?" — a partner who throws these questions back at the buyer is trying to understand the business. Conversely, a partner who produces an estimate from nothing but the feature list you handed over has a constitution that accepts blind hand-off.
When I worked on the lumber-distribution DX, the first thing I did was not to build features but to put the multi-stage commercial flow — "forestry → market → sawmill → pre-cut → builder → manufacturer" — into words together with the people on the ground. Providing a path to import existing Excel files as-is, and designing the migration so the field didn't have to abandon the tools it was used to, was only possible because of that immersion in the business. Had I accepted a blind hand-off, this design would never have emerged.
3. Pattern ② "Multi-tier subcontracting" — can they disclose how many tiers down the implementer sits?
Symptoms and root cause
In Japanese system development, the multi-tier subcontracting structure — where a prime contractor wins the work and pushes implementation down to subcontractors and sub-subcontractors — is not uncommon. The company the buyer contracted with and the person who actually writes the code are separated by two or three tiers. Here's why that produces collapse.
発注者 → 元請け（要件・営業）
→ 1次下請け（設計）
→ 2次下請け（実装）
→ 3次下請け（実際にコードを書く人）
・各層で中間マージンが抜かれ、末端に届く品質原資が削られる
・障害時に「どこの責任か」がたらい回しになる（責任分界の消失）
・末端の実装者は業務も発注者の意図も知らされない（丸投げの連鎖）
Because an intermediary margin is skimmed at each layer, for the same order value, the effort and unit price that reach the person actually doing the work shrink. Why the cost breakdown becomes hard to see is also touched on in how to see through cost estimates and market rates, but multi-tier subcontracting is a classic cause of "looks cheap, but quality doesn't follow."
The selection criterion reasoned backward: can you pin down subcontracting in the contract?
Spotting multi-tier subcontracting is surprisingly easy. Just ask directly: "Who actually writes the code, and how many tiers down are they?" Then, at the contract stage, control subcontracting. The IPA Model Transaction/Contract for Information Systems (Second Edition) is precisely a public template that organizes this — whether subcontracting is permitted, the duty to disclose, and where liability divides — into contract clauses. Following it, the buyer should pin down the following in the contract.
- Whether subcontracting is permitted, and prior consent: don't let them push work to subcontractors on their own. If they subcontract, make the buyer's written consent a requirement.
- The duty to disclose subcontractors: have them disclose the company and team that will carry out the implementation.
- Clear division of liability: keep liability for failures and non-conformity (formerly "defects") from escaping to the bottom tier, and attribute it to the prime contractor.
The simplest option for structurally avoiding multi-tier subcontracting is to contract directly with the implementer. With a solo or small-team developer, or a development company that implements in-house, neither intermediary margins nor passing-the-buck on liability arise. I myself carry requirements definition, design, implementation, infrastructure, security, and operations end-to-end on my own, so the party the buyer contracts with and the person doing the work are always one and the same. Beyond "fast and cheap," this has the collapse-avoiding effect of fixing responsibility at a single point.
4. Pattern ③ "Broken communication" — can you talk directly with the implementer?
Symptoms and root cause
Broken communication is a by-product of multi-tier subcontracting, but it also happens on its own. The buyer's intent is diluted through a game of telephone — sales → PM → design → implementation — and by the time it reaches the implementer it's become something else. Or an answer to a question is delayed by days, and in the meantime the wrong implementation proceeds. Rework quietly destroys cost and schedule.
Requirements are never perfectly firm from the start. That's exactly why whether you can keep aligning understanding in short cycles is decisive. If this is broken, you lose the chance to correct the vagueness in requirements definition (the biggest cause of commissioning failure) later on.
The selection criterion reasoned backward: the distance between decision-maker and implementer
The criterion reasoned backward is simple: is it a setup where the commissioning decision-maker and the person who actually implements can talk directly and frequently? Check the following.
- Whether, in regular meetings or chat, you can interact with the person actually implementing (and it isn't only relayed messages via sales or a PM).
- Whether they show you something working in short cycles (one to two weeks) and align on direction each time.
- Whether answers to questions are fast. Speed of response translates directly into less rework.
Furthermore, a phased rollout that doesn't switch everything over at once is also insurance against broken communication. Set a period of coexistence — information sharing and visualization → migrating some operations → full migration — and build up the field's buy-in, and you can correct course before a misalignment becomes fatal. Designing a migration that doesn't halt legacy operations is also covered in the legacy-system modernization guide.
5. Pattern ④ "Neglected technical debt" — do they have quality gates?
Symptoms and root cause
This is the least visible and most expensive pattern. Right after delivery, it works. So the buyer accepts it, satisfied. But code with no tests, types, or documentation breaks every time you change it. Six months on, adding a single feature breaks the existing behavior, modification costs balloon, and it eventually becomes "a system too scary for anyone to touch."
The "2025 cliff" warned of in METI's DX Report — the problem of legacy that can't be maintained and has become a black box holding the business back — is precisely the accumulated consequence of leaving this technical debt unaddressed. If a cheap estimate was cheap because it "omitted non-functional requirements and quality assurance," the buyer pays that bill a few years later.
The selection criterion reasoned backward: can they speak to four quality gates as "structure"?
A partner who won't neglect technical debt secures quality not through individual carefulness but through mechanisms (structure). The buyer should demand that they have the following four as structure. These are also the differentiators I consistently build into every project.
| Quality gate to demand | Why it prevents collapse | Concrete examples |
|---|---|---|
| Automated tests | Mechanically verify that a change hasn't broken existing behavior. Make modification unscary | Unit/E2E tests, visualization of test coverage |
| Type safety / boundary validation | Make invalid data "unrepresentable" and reduce bugs structurally | Validate external input with TypeScript/Zod, ban any |
| CI/CD | Enforce tests, types, and static analysis every time rather than relying on manual review | Automatically run tests, type checks, and scans on push |
| Security audits | Leave an evidence trail of closing holes from the attacker's and auditor's perspective | Penetration testing, keeping a ledger of accepted risks |
This isn't abstract theory. On the lumber-distribution DX, after four rounds of security audits including third-party penetration testing across 15 real roles, we demonstrated zero missing-authentication defects across all 221 endpoints. On the payment platform, through the code structure of idempotency and atomic transactions, we keep double-charges in production at zero. Not "it works, so ship it," but "because it's hardened by verification, it can be safely changed later" — this is the essence of development that leaves no technical debt.
How to build security audits into a commission is summarized in the cost and process of web-application vulnerability assessment, and a concrete checklist for preventing payment/billing collapse in the procurement guide to idempotency for preventing payment double-charges.
6. A "quality-gate question list" for buyers
Let's distill the backward reasoning so far into a question list you can use in an actual sales meeting. The point is that you don't need to evaluate the substance of the answers technically. Whether the partner answers with a concrete mechanism in their own words on the spot, or hedges into abstractions — that alone lets you tell whether they're a partner who neglects technical debt.
| The buyer's question | A good answer (example) | Red flag |
|---|---|---|
| Do you write tests? Is coverage visualized? | Concrete: "We write unit and E2E tests and run them every time in CI" | "As needed" / "We check manually" |
| How do you ensure type safety? | "In TypeScript; we validate external input with Zod and don't use any" | Can't answer what the question means / "As long as it works, it's fine" |
| What's your mechanism for making changes safely? | "We enforce tests, type checks, and static analysis in CI" | "We're careful in review" (person-dependent, not a mechanism) |
| How do you verify security? | "We run penetration testing and keep a ledger of residual risks" | "The framework is safe, so it's fine" |
| Who actually writes the code, and how many tiers down are they? | Clearly discloses: "I (our own implementer) write it" | Reluctant to disclose / vague, "a partner company does" |
| Do the deliverables include source code, tests, and documentation? | "All included. The rights belong to you, too" | "Source is separate" / "Documentation is an extra charge" |
Run these six questions and you can flush out blind hand-off, multi-tier subcontracting, and neglected technical debt almost entirely before signing. The buyer can become the side that "gets to demand" quality gates. No specialist knowledge is needed; all you need is to know "what to ask."
An answer to "is quality safe with solo-developer × generative AI?": Lately, commissions to small-team × generative-AI developers like me are increasing. What makes "fast and cheap" possible is generative AI, but what secures "safety" is human verification gates. It's precisely because generative AI's output passes through multiple layers of mechanisms that don't trust it as-is — validation at type-safe boundaries, automated tests, static analysis, security scanning, and third-party penetration testing — that a small team reaches production quality. The question list above is effective precisely against a small-team partner.
7. Sealing off collapse at the contract stage — clauses to include
Finally, the contract after selection is done. The patterns of collapse can be sealed off institutionally by writing them into the contract as clauses. Building on the IPA Model Transaction/Contract for Information Systems, spell out at least the following.
- Control of subcontracting (→ countering multi-tier subcontracting): whether subcontracting is permitted, prior consent, the duty to disclose, and the division of liability.
- Agreement on non-functional requirements (→ countering technical debt): pin down the levels of performance, availability, security, and operations in numbers, referring to the IPA Non-functional Requirements Grades. Define "fast" and "safe" by criteria, not words.
- Acceptance criteria and tests (→ countering blind hand-off): define in advance, as test pass/fail criteria, what constitutes "completion."
- Scope and rights of deliverables (→ countering technical debt and vendor lock-in): include source code, tests, and documentation in the deliverables, and spell out the ownership of copyright. Without this, you can't hand off to another firm later and are effectively locked in.
- Non-conformity liability and maintenance: the term of post-delivery non-conformity (formerly "warranty against defects") and the treatment of maintenance fees (generally, a rough guide of around 15% of the development cost per year).
These aren't "for when a dispute arises." The real value is that in the process of writing them in, whether the partner carries a pattern of collapse comes to light. Reluctance to disclose subcontracting, distaste for quantifying non-functional requirements, making source-code delivery an extra charge — such reactions tell you the partner's constitution before you sign.
Conclusion: don't "search around" for it — "rule out collapse by reasoning backward"
Choosing a development company that won't fail you is not a contest of intuition to hunt down a good company. It's the work of ruling out, one by one through backward reasoning, the four structures that produce collapse.
- Blind hand-off → choose a partner who can propose not building and turn non-functional requirements back to you as questions.
- Multi-tier subcontracting → have them disclose how many tiers down the implementer sits, and pin down subcontracting in the contract.
- Broken communication → choose a setup where the decision-maker and the implementer can talk directly and frequently.
- Neglected technical debt → choose a partner who can speak to quality gates like testing, type safety, CI, and security audits as structure.
And your greatest weapon is the buyer themselves becoming the side that "gets to demand" quality gates. With the question list from Chapter 6 in hand, even without specialist knowledge you can greatly lower the risk of collapse before signing.
From DX for legacy industries, to new development and turnaround of B2B SaaS, to payment/billing platforms, to putting generative AI to work in operations, I take on the whole span from requirements definition through infrastructure, security, and operations end-to-end on my own, and I secure that quality with the verification gates of "type safety, testing, security audits, and idempotency." If you're considering commissioning work, let's start by inspecting together whether your setup is "built not to collapse."