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

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: Article numbers and wording for the Civil Code, the Copyright Act, and other statutes follow the current text on e-Gov Law Search (checked on 3 October 2026); the content and effective date of the amendments follow the Ministry of Justice and the IPA "Model Transaction/Contract for Information Systems." The quantitative figures tied to my real projects (zero production double-charges, four rounds of self-conducted 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.

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 and how to see through cost estimates and market rates. 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 on 1 April 2020 (Act No. 44 of 2017), the former "warranty-against-defects liability" was restructured into "non-conformity liability." The word for "defect" (瑕疵, kashi) disappeared from the contract-for-work provisions; the test is now whether the delivered work "does not conform to the terms of the contract" in kind, quality, and so on. If you still see "warranty against defects" (瑕疵担保) in a contract or quote today, take it as a prompt to check whether a pre-amendment template is being reused. The IPA "Model Transaction/Contract for Information Systems" has also been revised in line with this amendment.

Here it is, article by article, from the buyer's perspective.

• Four remedies — demanding cure (repair) of the performance (Article 562), a reduction of the fee (Article 563), damages (Articles 564 and 415), and rescission (Articles 564, 541, and 542). Cure and fee reduction are sale provisions that Article 559 applies to other contracts for value, including contract-for-work; damages and rescission come from the general rules on non-performance (Articles 415, 541 and 542), which Article 564 confirms remain available.
• The notice period — if the buyer does not give notice within one year of learning of the non-conformity, those four remedies are lost (Article 637(1)). Before the amendment, the claim itself had to be made "within one year of delivery" (former Article 637), so the starting point now favors the buyer. The one-year limit also does not apply if, at delivery, the contractor knew of the non-conformity or failed to know of it through gross negligence (Article 637(2)). Once notice is given, the right itself is subject to the general extinctive prescription for claims (Article 166(1): five years from when you learn you can exercise it, ten years from when it becomes exercisable).
• Non-conformities caused by the buyer's instructions are excluded — as a rule, the buyer cannot pursue liability for a non-conformity caused by the nature of materials the buyer supplied or by the buyer's instructions (Article 636). The exception is when the contractor knew the materials or instructions were unsuitable and did not say so. Whether your counterpart pushes back on a bad instruction, rather than stopping at "I built what I was told," therefore matters legally too.
• The period is set by contract in practice — it is common to set a separate period such as "○ months from completion of acceptance" in the contract, and the IPA revision materials likewise treat how to design this starting point as a point of discussion. Note that even a clause excluding liability does not release the contractor from liability for facts it knew and did not disclose (Article 572, applied to contract-for-work through Article 559).

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." For reference, on the contract-for-work engagements I take, the default is that defects found within 3 months after acceptance are fixed free of charge (the period and other terms are adjusted per contract).

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.

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 8).

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.

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.

【要件定義・調査フェーズ】
  → 準委任（成果完成型 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, and the context of legacy modernization in the 2025 cliff and legacy modernization.

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). The Copyright Act makes the person who creates a work its author (Article 2(1)(ii)) and gives the author the copyright (Article 17). If the contractor is a company, a program its employees create in the course of their duties on the company's initiative is authored by the company unless a contract, work rules, or the like provide otherwise (Article 15(2)). 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.

There are further points you must always confirm in practice.

• Name the Article 27 and 28 rights — in a contract that only says "copyright is assigned," the adaptation rights and the like (Article 27) and the rights over the use of derivative works (Article 28) are presumed to remain with the assignor (Article 61(2)). For software you will keep modifying, that is fatal, so have the clause say "copyright (including the rights provided in Articles 27 and 28 of the Copyright Act) is assigned."
• 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. What the buyer should own — not just the rights, but "where it lives" and "the keys"

Chapter 6 was about rights. But even if the contract assigns you the copyright, as long as the place the source code lives, the cloud, and the domain stay in the vendor's name, the keys that run the system are in their hands. Whatever the contract type — contract-for-work, quasi-mandate, or lab-type — here is what the buyer should hold in its own name.

The key point is that creating these in the buyer's name from the start is safer than having them handed over at delivery. A transfer at delivery depends on the vendor's cooperation, and it stalls precisely when the relationship has gone sour. If everything is in your name from the start, however the relationship ends, all you do is revoke the vendor's access. The full set of checks — including admin rights, automated tests, and the period of non-conformity liability — is in the checklist of what the buyer should own from day one in the complete guide to commissioning system development.

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, and the infrastructure is managed as IaC such as Terraform and delivered in a state another engineer can rebuild. What I cover as the technical lead for a company with no engineers in-house, and the indicative pricing, are on the fractional CTO page.

8. 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 platforms I built, four rounds of self-conducted security audits (the lumber-distribution DX) and 100% backend test coverage (the AI video-localization platform, where CI fails the build if it isn't met) 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.

9. 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.

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

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

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 in writing (a purchase order and the like) is not only basic practice; depending on the parties and the kind of work commissioned, it is a legal obligation. When work is commissioned from an individual who uses no employees (among others), Article 3 of Japan's Freelance Act applies; when the size of both businesses and the kind of work meet certain requirements, Article 4 of the 取適法 (the Act formerly known as the Subcontract Act, renamed by an amendment in force from 1 January 2026) applies. Both require the content of the work, the amount of the fee, the payment date, and other terms to be stated in writing or by electronic means. The basic rule of "don't proceed on a verbal order" applies regardless of contract type.

10. 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
• If assigned, does the clause name the rights in Articles 27 and 28 of the Copyright Act
• Is a covenant not to exercise moral rights included
• Will the repository, cloud accounts, and domain be created in the buyer's name from day one
• Are a README, an architecture diagram, an environment-variable list, and a runbook written into the contract as deliverables
• 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.

11. 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. For the contract and payment cautions when using subsidies, see the complete guide to subsidies × system development. 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.