# Contract-for-work, quasi-mandate, or lab-type: choosing a system-development contract [a buyer's guide]

> A buyer's-eye guide to system-development contract types. When to use contract-for-work (deliverable + non-conformity liability), quasi-mandate (effort + duty of care), and lab-type; plus how to handle IP, acceptance testing, and additional requirements — systematized from real projects including a METI Minister's Award winner and a payment platform with zero production double-charges.

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

## Key points

- A contract type is a choice between 'buying a deliverable' (contract-for-work) and 'buying time and a team' (quasi-mandate / lab-type), and it's decided by how firm your requirements are — pick contract-for-work while requirements are still fluid and you fight over every change.
- Contract-for-work promises 'completion of the work' and carries non-conformity liability (formerly warranty-against-defects liability). Quasi-mandate carries a 'duty of care' but does not guarantee a deliverable. Lab-type applies quasi-mandate to secure a continuous, dedicated team.
- IP (copyright) by default 'stays with the developer if you do nothing.' Unless the contract spells out assignment vs. license and how general-purpose modules and OSS are handled, reuse becomes a source of disputes.
- Acceptance testing is all about 'putting the pass/fail criteria into words before you order.' With vague criteria, acceptance never finishes even under contract-for-work — and neither payment nor maintenance can begin.
- Treat additional requirements as a given and build a change-management process into the contract. Quasi-mandate and lab-type absorb change well; contract-for-work holds a fixed scope but makes changes expensive.

---

Let me give the conclusion first. **Choosing a system-development contract type ultimately comes down to a single decision: are you "buying a deliverable" (contract-for-work, or _ukeoi_) or "buying time and a team" (quasi-mandate, or _jun-inin_ / lab-type)? And the right answer is decided not by the development company but by "how firm your requirements are."** Hand everything off under quasi-mandate while your requirements are firm and you lose any guarantee of a deliverable; lock in contract-for-work while requirements are still fluid and you incur extra costs and renegotiation on every change. The first step is to understand a contract type not as "a tool to bind the other party" but as "an agreement on which side takes on how much of the uncertainty."

This article draws on the contract, acceptance-testing, and change-management practice from 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**, and an enterprise AI platform for a major domestic broadcaster — to offer buyers (executives, business owners, and IT/information-systems staff) a map for not losing out. Note that I am not a lawyer; always confirm final legal judgments with a professional. This article is a practitioner's explanation.

> **Stating the premises**: The Civil Code definitions and the content of the amendments are based on the IPA "Model Transaction/Contract for Information Systems" and the Civil Code articles on e-Gov Law Search. The quantitative figures tied to my real projects (zero production double-charges, four rounds of security audits, and so on) are actual measurements verifiable from the repositories. I do not assert business ROI (revenue or percentage reduction in labor) because that requires the client's real data.

---

## 1. Understanding the three contract types on a single page

In practice, the contracts used in system development boil down to roughly the following three. Let's grasp the whole picture on a single page first.

| Aspect | Contract-for-work | Quasi-mandate (proportional-performance type) | Lab-type contract |
|---|---|---|---|
| What you're buying | **A deliverable** (a completed system) | **Effort** (the performance of the work itself) | **A dedicated team for a fixed period** (a block of effort) |
| The developer's promise | A **duty to complete** the work | A **duty of care** (perform in good faith) | Duty of care (quasi-mandate is the base) |
| Deliverable guarantee | Yes (non-conformity liability) | No (completion not guaranteed) | No (providing the team is the point) |
| How the fee is set | Fixed against the deliverable | Against hours worked / person-months | Period × headcount (a monthly block) |
| Basis in the Civil Code | Art. 632 onward | Arts. 643, 644, 656 | No explicit provision (an application of quasi-mandate) |
| Where it fits | Development with firm requirements | Investigation/improvement with fluid requirements | Agile, continuous development |
| The buyer's main risk | Cost rises on every change | You pay even for effort that yields no result | Wasted effort / a team spinning idle |

The contrast to remember is simple: **contract-for-work pays for the "result," while quasi-mandate and lab-type pay for the "process" (time and team).** With that one axis as the anchor, we'll dig into each below. The upstream questions before choosing a contract type — "should you build it at all" and "what's the going rate" — are covered in the [complete guide to commissioning system development](/blog/system-development-outsourcing-guide-vendor-selection-cost) and [how to see through cost estimates and market rates](/blog/system-development-cost-estimate-market-rate-guide). This article focuses on the contract design of "whom to ask, and how."

---

## 2. Contract-for-work — promising "completion" and carrying non-conformity liability

Contract-for-work, set out in Article 632 of the Civil Code, is a contract that **pays remuneration for the "completion of the work."** The development company bears the duty to complete the system it promised, and as a rule cannot claim payment if it fails to complete it. From the buyer's viewpoint, "you get exactly the spec you agreed on, at the price you agreed on" — it looks like the most reassuring arrangement.

### 2.1 Non-conformity liability (formerly warranty-against-defects liability)

The crux of contract-for-work is liability when the delivered work has a defect (a bug or a mismatch with the spec). Under the amended Civil Code that took effect in April 2020, the former "warranty-against-defects liability" was restructured into **"non-conformity liability."** The IPA "Model Transaction/Contract for Information Systems" has also been revised in line with this amendment.

Here are the key points of the amendment from the buyer's perspective.

- **When a non-conformity exists, the buyer may seek "cure (repair)," "reduction of remuneration," "damages," or "rescission of the contract"** — the remedies were organized in explicit statutory terms.
- As a rule, the period for pursuing liability under the Civil Code only requires that you **"give notice within one year of learning of the non-conformity"** (in some respects more favorable to the buyer than the pre-amendment "one year from delivery").
- In practice, however, it is common to separately set a period such as **"○ months from completion of acceptance"** in the contract. The IPA revision materials likewise treat how to design this starting point as a point of discussion.

What the buyer should check is **the term of the non-conformity liability and how it hands off to the subsequent maintenance contract.** Always read for "whether the warranty period is too short" and "whether it's designed to switch to paid maintenance the moment the warranty period ends."

### 2.2 The pitfall of contract-for-work — the flip side of "fixed"

The reassurance of contract-for-work comes at a price: **a fixed price and fixed scope only hold up once your requirements are firm.** Sign a contract-for-work while requirements are still vague, and either the developer pads the estimate high to absorb the uncertainty, or you end up in a back-and-forth of extra charges — "that's outside the contract scope" — later on. This is the classic failure I've seen over and over in the field.

In short, contract-for-work only shows its strength once you've reached "the stage where you can write a spec," and is ill-suited to projects still in the exploratory stage.

---

## 3. Quasi-mandate — carrying a "duty of care" and paying for effort

Quasi-mandate is a contract based on Article 656 of the Civil Code (the entrustment of non-legal-act affairs), under which the development company bears the **"duty to perform the work with the care of a good manager" (the duty of care, Article 644).** The decisive difference from contract-for-work is that it **does not promise "completion."** As long as the work is performed faithfully and professionally, remuneration accrues for that effort even if it falls short of the intended result.

You might feel, "If the deliverable isn't guaranteed, isn't that bad for the buyer?" But for projects with fluid requirements, quasi-mandate is the more rational choice — because **you don't have to renegotiate the contract scope on every change, and you can firm up requirements as you experiment.** It shines in "you won't know until you try" territory: requirements definition, investigation, PoCs, and operational improvement.

### 3.1 "Proportional-performance type" vs. "result-completion type"

The amended Civil Code organized how remuneration is paid under quasi-mandate into two forms. Knowing this difference puts the buyer in a stronger negotiating position.

| Type | What the fee is for | Civil Code | Where it fits |
|---|---|---|---|
| **Proportional-performance type** | The proportion actually worked (hours / person-months) | Art. 648 | Continuous work, operations, improvement |
| **Result-completion type** | Completion of a defined result | Art. 648-2 | Work with a clear result, such as an investigation report or a PoC |

Quasi-mandate is not just "settling by the hour." Using the result-completion type, you can design a contract that, **while still a quasi-mandate, "pays once a specific deliverable is produced."** It's an effective middle ground for "I don't want to impose a completion duty as rigidly as contract-for-work, but I do want to tie payment to a result."

### 3.2 What the buyer must uphold under quasi-mandate

Quasi-mandate is flexible, but left unattended it invites a state where "people are working but nothing moves forward." The buyer should guard against the following three things.

1. **Demand visibility into the work** — make weekly progress, effort, and decision logs mandatory. Handing everything off blindly is the worst possible fit for quasi-mandate.
2. **Set agreed checkpoints for interim results** — review "what got done" at each sprint or milestone.
3. **Make the substance of the duty of care concrete** — translate "the quality any professional owes" into observable criteria such as testing, type safety, and security (Chapter 7).

---

## 4. Lab-type contract — an application of quasi-mandate to "continuously secure a dedicated team"

Lab-type is **a commercial practice, not a legal category.** In substance it is based on quasi-mandate and refers to an arrangement where you **secure a dedicated development team for a fixed period (say, six months to a year) and pay a monthly fee against that period's block of effort.** It's sometimes called an "offshore lab" or a "lab contract."

The value of lab-type over contract-for-work, where you re-commission each project, lies in the fact that **the team keeps accumulating domain knowledge.** In domains where understanding the domain drives quality — a multi-stage commercial flow like the lumber-distribution DX ("forestry → market → sawmill → pre-cut → builder → manufacturer"), or idempotency design for a payment platform — a lab-type where the same team improves continuously is often faster and cheaper overall than a contract-for-work where the team turns over every time.

| Comparison axis | Contract-for-work (per-project) | Lab-type (continuous team) |
|---|---|---|
| Domain knowledge | Relearned each project | Accumulates and compounds in the team |
| Requirement changes | Requires a contract change | Absorbed flexibly within the block |
| Ramp-up cost | Incurred every time | Only the first time |
| Best suited to | One-off, spec-fixed development | Products you keep growing |
| Buyer involvement | Centered on acceptance | Continuous prioritization is essential |

The risk of lab-type is "the block of effort going unfilled and idle." If there's no product owner on the buyer's side, the team you've secured just spins its wheels. **Lab-type is a contract premised on the buyer being able to keep supplying priorities.** For teams that sustain agile development, the IPA has separately prepared an "agile-development edition" of its model contract.

---

## 5. How to use them selectively — switch contracts by phase

In real, larger projects, **rather than running a single contract type from start to finish, it's optimal to use them selectively by phase.** Here's the typical structure I adopt in practice.

```text
【要件定義・調査フェーズ】
  → 準委任（成果完成型 or 履行割合型）
    要件が固まっていないので「完成」を約束できない。
    ここで請負にすると、双方が不確実性を抱えて破綻する。
        │
        ▼  要件が仕様書レベルまで固まる
【設計・実装フェーズ】
  → 要件が固いなら請負 / 変わり続けるなら準委任・ラボ型
    ・スコープが確定 → 請負で「決めた範囲を固定価格」
    ・探索と改善が続く → 準委任 or ラボ型で柔軟に
        │
        ▼  リリース後
【運用・保守・継続改善フェーズ】
  → 準委任 / ラボ型（＋ 契約不適合責任からの引き継ぎ）
    育て続けるプロダクトはラボ型が総合的に有利。
```

The core question for the decision is consistently **"At this stage, can I lock the spec down as fixed?"** If you can, go contract-for-work; if you can't, go quasi-mandate or lab-type. Skipping this judgment and pushing ahead with "let's just do it all as contract-for-work" is the single biggest breeding ground for extra-cost disputes. The further-upstream decisions of "in-house vs. outsource" and "SaaS vs. from-scratch" are covered in the [build-vs-buy decision guide](/blog/build-vs-buy-saas-vs-scratch-inhouse-vs-outsource-guide), and the context of legacy modernization in [the 2025 cliff and legacy modernization](/blog/legacy-system-modernization-2025-cliff-cost-guide).

---

## 6. Handling IP (copyright) — "it stays with the developer if you do nothing"

Alongside the contract type, what buyers most often overlook is **the ownership of intellectual property rights (copyright in particular).** This must be defined independently, whether under contract-for-work or quasi-mandate.

**Don't misunderstand the default rule. If the contract defines nothing, the copyright in the program that was developed belongs to the party that created it (the contractor).** Having paid to have it built does not automatically make it the buyer's. If you as the buyer want to freely modify and reuse the source code, it must be spelled out in the contract.

| How it's defined | What it means | What it means for the buyer |
|---|---|---|
| **Assignment of copyright** | Transfers the deliverable's copyright to the buyer | Free to modify, reuse, and commission other firms. The greatest freedom |
| **License** | Copyright stays with the developer; the scope of use is licensed | Usable, but constraints may remain on modification or repurposing beyond the scope |
| **Covenant not to exercise moral rights** | An agreement not to exercise moral rights (which cannot be assigned) | A practical must for smoothly allowing modification, omitting credit, and the like |

There are further points you must always confirm in practice.

- **Handling of general-purpose modules and in-house libraries** — shared components that the development company also uses on other projects are customarily excluded from what is assigned and kept to a "license." Push for "assign everything" across the board, and either the unit price rises or the good firms steer clear. Agreeing on where the line falls matters.
- **Handling of OSS (open source)** — OSS embedded in the deliverable cannot be assigned in the first place. Obligations differ by license: MIT, Apache-2.0, the GPL family, and so on. Having the vendor **include a list of "which OSS was used under which license" (equivalent to an SBOM) in the deliverables** is the practice that avoids later legal and security risk.
- **Handling of code that generative AI was involved in** — I use solo-developer × generative AI (Claude Code) as an accelerator, but generated output only becomes a deliverable after passing a human verification gate, and I settle copyright and licensing in the contract within the same framework as ordinary OSS/hand-written code. What matters is leaving no state of "rights are murky because AI wrote it."

The IPA model contract also includes template IP clauses for copyright, patents, and the like, which are useful as a starting point for negotiation.

---

## 7. Designing acceptance testing — put the pass/fail criteria into words "before you order"

**Acceptance testing, even under a contract-for-work, will never end if the pass/fail criteria are vague.** And until acceptance finishes, nothing begins — not payment, not the clock on non-conformity liability, not the transition to a maintenance contract. Acceptance is not "work you do after delivery" but "**something you design before you order.**"

Here is the acceptance design I always ask for on the buyer's side.

1. **Define pass/fail criteria on both functional and non-functional axes** — not just "it works" but "up to what load / in which browsers / at what response time," in numbers. Acceptance specs that omit the non-functional side are the source of later "it's slow" / "it crashes" disputes.
2. **Present the test perspectives yourself** — not just the happy path but error cases and boundary values. The reason the payment platform maintains **zero production double-charges** is that idempotency was explicitly built into the acceptance perspectives and tests for retries and duplicate requests were made pass/fail conditions. Make "double-charges won't happen" an acceptance item, not a wish.
3. **Include quality gates in the pass/fail criteria** — test coverage, type safety, and vulnerabilities. On the platform I built, **four rounds of security audits** and **100% test coverage** (for the target modules) were operated as passing conditions. A quality gate is the "duty of care" and "non-conformity" translated into observable criteria.
4. **Check the acceptance period and any "deemed acceptance" clause** — contracts often contain a clause that automatically treats the work as accepted if the buyer says nothing within the period. Leaving it unattended is not an option.

If you can put the acceptance criteria into words before you order, disputes drop dramatically under either contract-for-work or quasi-mandate. Conversely, no matter how fine the contract, if the pass/fail criterion is a subjective phrase like "the buyer is satisfied," you will always end up in a fight.

---

## 8. Handling additional requirements and spec changes — design on the premise that they will occur

No system-development project exists in which spec changes **do not** occur. That's why a good contract doesn't "forbid changes" but has "**a procedure for handling changes safely**" from the outset.

How well each contract type withstands change differs structurally.

| Contract type | Resilience to change | How changes are handled |
|---|---|---|
| Contract-for-work | Weak (fixed scope is the premise) | A change = a contract change. Agree effort, cost, and schedule each time via a **change-management (CR) process** |
| Quasi-mandate | Strong | Absorbed as a priority for the next sprint. A contract change is generally unnecessary |
| Lab-type | Strong | Handled by reshuffling priorities within the secured block of effort |

If you choose contract-for-work, the buyer must always put a **change-management (Change Request) process** into the contract.

```text
変更要望
  → 影響分析（工数・費用・納期・他機能への波及を開発側が提示）
  → 発注者が承認 / 却下 / 保留を判断
  → 承認なら見積・契約変更 → 実装
  → 却下でも記録を残す（言った言わないを防ぐ）
```

Without this process, "a change I thought was minor" turns into a tug-of-war over free work and the relationship breaks down. **Changes will happen. So decide in advance how you'll decide when they do** — this is the only way to prevent disputes over additional requirements. The correct understanding is that with quasi-mandate and lab-type, this flexibility is built into the contract structure from the start.

Note that putting the transaction terms between buyer and vendor in writing (a purchase order and the like) is also practically important from the standpoint of the Subcontract Act and freelancer protection. The basic rule of "don't proceed on a verbal order" applies regardless of contract type.

---

## 9. A checklist for buyers

Here are the items a buyer should confirm at a minimum before signing the contract. It's a practical checklist you can print and bring to a meeting with the development company.

- [ ] **Does the contract type match how firm the requirements are** (firm → contract-for-work / fluid → quasi-mandate or lab-type)
- [ ] For quasi-mandate, is it **proportional-performance or result-completion type**, and is how the fee is paid clear
- [ ] For contract-for-work, are the **term of non-conformity liability** and the handoff to the maintenance contract reasonable
- [ ] **Is copyright assigned or licensed**, and is the handling of general-purpose modules and OSS spelled out
- [ ] Is a **covenant not to exercise moral rights** included
- [ ] Do the deliverables include an **OSS list (equivalent to an SBOM)**
- [ ] Are the **acceptance pass/fail criteria** quantified on both functional and non-functional axes
- [ ] Are **quality gates** (testing, type safety, security) included in the acceptance conditions
- [ ] Do you understand the period and conditions of any **deemed-acceptance** clause
- [ ] Is a **change-management (CR) process** defined
- [ ] Whether **subcontracting** is permitted and, if so, where liability rests
- [ ] The settlement method on **early termination** (especially quasi-mandate and lab-type)

These are the items I've used repeatedly, from both the buyer's and the vendor's side, as the "minimum line for not ending up in a fight." Work through them one by one and you can nip most of the trouble in the bud at the contract stage.

---

## 10. Conclusion — a contract is an agreement that decides "the distribution of uncertainty"

To sum up the choice of contract type in one line: **contract-for-work is a contract that "fixes the scope in exchange for the developer taking on the uncertainty." Quasi-mandate and lab-type are contracts that "gain flexibility in exchange for sharing the uncertainty with the buyer."** It's not about which is better, but about which phase your project is in right now.

I develop fast and cheap with solo-developer × generative AI (Claude Code) as an accelerator. But "cheap and fast" alone doesn't earn a buyer's trust. **It only becomes value once "safety" is secured by human verification gates — putting acceptance criteria into words, quality gates, and change management** — a principle I've upheld consistently on the METI Minister's Award B2B SaaS and the zero-double-charge payment platform. A contract is nothing other than the device that fixes that safety in legal language.

The upstream questions before the contract type — "should you build it at all," "what's a fair price," and "whom to ask" — are systematized in the [complete guide to commissioning system development](/blog/system-development-outsourcing-guide-vendor-selection-cost). For the contract and payment cautions when using subsidies, see the [complete guide to subsidies × system development](/blog/subsidy-system-development-outsourcing-complete-guide). If you're unsure how to decide, bring me a draft contract and let's talk. We'll design it together, starting from how to choose the contract type.