TroubleshootingBBothIntermediate

Deliverable Defects — Liability Scope and Repair Obligations

A practical guide with legal grounding on the liability scope, repair obligations, and cost responsibility for defects discovered after delivery, for both contractors and clients

Three weeks after delivering a web system, contractor A received a report that "the login function throws an error in a specific environment." A considered acceptance complete, but the client insists "this is a defect and must be fixed at no charge."

Meanwhile, a project manager at production company B discovered a shopping cart malfunction after delivering an e-commerce site. The bug only reproduces in a browser not listed in the contract's supported environments, but end users are starting to be affected. The development vendor maintains that "operation in environments not defined in the specifications is not guaranteed."

Disputes over deliverable defects like these occur daily in freelance and outsourced work environments. Without an accurate understanding of both parties' legal rights and obligations around "bug repair obligations" and "post-delivery defects," two types of failure occur: forced unpaid labor or the abandonment of legitimate rights.

The Reality of Post-Delivery Defects

This section organizes the patterns of defect disputes that actually occur in production environments and the losses they bring to both parties.

Typical Defect Dispute Patterns

Pattern 1: Hidden Defects Discovered After Acceptance

A web application functioned normally during acceptance testing, but performance degrades significantly as data volume grows after migration to the production environment. The cause is the difference in data scale between the testing and production environments. The contractor argues "there were no issues at acceptance," while the client argues "if it doesn't work in production, it's a defect."

Pattern 2: Bugs from Specification Interpretation Gaps

For a specification calling for "a product list users can freely reorder," the contractor implemented only drag-and-drop functionality. However, the client interpreted this to include reordering by number input, and after delivery requested a fix for "not meeting the specification." Because the specification document was ambiguous, both parties had grounds for their claims.

Pattern 3: Defects That Only Reproduce in Third-Party Environments

A delivered smartphone UI is discovered to have display issues on a specific device model belonging to the client's customers. The model is not included in the contract's supported device list, but the client argues "isn't it a defect if it doesn't work on a supported model?"

Pattern 4: Design Problems That Surface During Operation

Six months after launch, a security audit discovers an SQL injection vulnerability. The contractor argues "we complied with the security standards at the time of development," but the client is seeking damages from a personal information protection standpoint.

Losses from Defect Disputes

Impact on Contractors

The most serious risk is unpaid remaining compensation. If a client's argument that "we won't pay the balance until the defect is resolved" is upheld, payment for a nearly complete deliverable remains in limbo. The time spent on free repair work also represents direct opportunity cost — one week of repair work means lost revenue for that period.

Psychological costs cannot be ignored either. The recognition that "something I built has a defect" damages a creator's motivation. Even when a free repair demand is unjust, not responding carries the risk of relationship deterioration and reputational damage.

Impact on Clients

Defects in production directly affect end users. For an e-commerce site, this means lost sales opportunities; for a business system, there is risk of operational stoppage. Alternative measures must be arranged while repairs are completed, generating additional costs.

Negotiations or litigation with the contractor take time and money. The psychological exhaustion of not receiving the expected quality is also significant.

This section organizes the legal mechanisms underlying defect liability. The contract type and the nature of the defect determine whether a repair obligation exists.

The Difference Between Fixed-Price and Time-and-Materials Contracts

Fixed-Price Contract (Civil Code Article 632)

A fixed-price contract is one whose purpose is "completion of work." When a specific deliverable is promised — such as website creation, system development, or video production — the contract is normally treated as fixed-price.

Under a fixed-price contract, the contractor is promising the result of "completing work that conforms to the contract." If the completed work does not conform to the contract (non-conformity), the client holds rights to demand repair, price reduction, damages, and contract cancellation (Civil Code Articles 559, 562 et seq.).

This "non-conformity liability" is the modern expression of what was traditionally called warranty liability.

Time-and-Materials Contract (Civil Code Article 656)

A time-and-materials contract is one whose purpose is "performance of work." Consulting, ongoing operational management, and maintenance work that does not promise a specific result fall under this category.

Under a time-and-materials contract, the contractor is only promising "to perform the work with due care" — not guaranteeing a specific result. Therefore, a defect in the deliverable does not automatically give rise to a repair obligation; liability is evaluated from the perspective of "whether reasonable care was exercised in the work."

Practical Caution

Whether a contract is fixed-price or time-and-materials cannot be determined from the contract name "outsourcing agreement" alone. It is necessary to judge comprehensively based on the contract terms, the payment structure (lump-sum upon completion or monthly), and the actual nature of the work. In ambiguous cases, courts judge based on the actual situation — there is a risk that arguing "it was time-and-materials so I have no liability for results" after the fact may not be accepted.

Distinguishing "Specification Bugs" from "Implementation Bugs"

A critical question in considering defect liability is: "What caused the defect?"

Implementation Bug (Contractor's Responsibility)

When a function clearly defined in the specifications does not operate as defined, this is called an "implementation bug." For example, when an error page appears despite the specification stating "after login, transition to My Page." This is an error in the contractor's implementation and in principle carries a free repair obligation.

Specification Bug (Client's or Shared Responsibility)

When the specification definition itself is incomplete or contradictory, this is called a "specification bug." The contractor implemented according to the specification, but the specification itself did not meet the actual business requirements.

Responsibility for specification bugs lies primarily with whoever handled the requirements definition (usually the client, or a contractor who performed requirements definition under the client's direction). However, if the contractor noticed that "this specification cannot meet the requirements" but failed to point it out, there is a possibility that the contractor bears some responsibility for breach of duty of care.

Problems Outside Supported Environments and Prerequisites

In principle, defects in environments other than the browsers, OS, and versions specified in the contract or specifications are outside the contractor's repair obligation scope. However, when there is no specification regarding "environments that should obviously be supported as industry standard," disputes are likely.

Notification Period for Non-Conformity Liability

Under Civil Code Article 566, the client must notify the contractor within one year from when they became aware of the non-conformity, or they lose the right to demand repair, price reduction, damages, and contract cancellation.

Note that this is "one year from when they knew" — not "one year from delivery." For defects discovered later, rights can be preserved by notifying within one year of discovery.

However, this one-year period can be freely modified by the parties. It is common to specify "6 months after acceptance completion" or "1 year from delivery" in the contract. Contractors have an interest in setting a shorter period, while clients have an interest in a longer period.

Contractor Liability Scope and Response Methods

This section shows the specific action steps contractors should take when a defect occurs, and how to handle unjust free repair demands.

Confirming the Reach of Free Repair Obligations

Upon receiving a defect report, first confirm the following points:

  1. Contract type confirmation: Fixed-price or time-and-materials? For fixed-price, non-conformity liability may be invoked
  2. Nature of the defect: Implementation bug (not working as specified), specification bug, or problem outside supported environments
  3. Acceptance status and timing: Has acceptance been completed? If so, how many months have passed since?
  4. Warranty clauses in the contract: Are the scope, period, and exclusions for free repair defined?

For implementation bugs, a repair obligation exists in principle even after acceptance. However, if the contract specifies a warranty period (e.g., "3 months after acceptance"), this provides grounds for treating repairs after that period as paid work.

Step-by-Step Defect Response Procedure

Step 1: Fact Confirmation and Recording

Upon receiving a defect report, first confirm the details of what occurred. Record the reproduction steps, environment, and scope of impact in writing (email or chat). Follow up any verbal reports with written confirmation via email.

Step 2: Classifying the Nature of the Defect

Analyze technically whether it is an implementation bug or specification bug. Organize specifications, design documents, and communication records as evidence. Clarify "which specification description was the basis for this implementation."

Step 3: Determining Repair Obligation

If it is an implementation bug within the warranty period, there is a free repair obligation. If it is a specification bug or a problem outside supported environments, repair can be proposed as a paid engagement. If the warranty period has passed, paid repair is the default while partial free repair for relationship maintenance may also be considered.

Step 4: Explanation to Client and Obtaining Agreement

Explain the presence or absence and scope of repair obligation in writing with supporting rationale. For paid repairs, present a quote and obtain client approval before beginning work. Starting with "let me take a look first" makes it difficult to later claim payment.

Handling Unjust Free Repair Demands

When a client argues "everything is defective, fix everything for free," take the following approach:

Leveraging Evidence

Organize specifications, design documents, acceptance-phase communications, and approval emails to compile documents that demonstrate "the work was completed within the scope of the contractor's obligations."

Presenting Alternatives

Make a written proposal that "free handling is not possible, but paid handling is possible." When prioritizing relationship maintenance, some contractors will say "we'll handle part of this for free as a special exception this time, but similar requests going forward will be paid," making this explicit before proceeding.

Preparing Written Notices and Legal Options

If negotiations do not progress, consider consulting an attorney. When the cost-benefit does not justify the expense, small claims court (amounts under 600,000 yen) or a payment order are also options.

Client Rights and Exercise Procedures

This section organizes the legal rights clients hold when defects occur and the practical procedures for exercising them appropriately.

Four Rights Clients Hold

Under non-conformity liability as defined by the Civil Code, clients hold the following rights:

1. Right to Demand Repair (Civil Code Article 562)

The right to demand correction or completion of the defective portion. A demand to "fix the bug" falls under this right. The contractor has an obligation in principle to comply, but may refuse if repairs would require disproportionate expense.

2. Right to Demand Price Reduction (Civil Code Article 563)

When repair is impossible or the contractor refuses to repair, the right to demand a price reduction proportionate to the degree of the defect. Used as an alternative to the demand for repair.

3. Right to Claim Damages (Civil Code Articles 564, 415)

The right to seek compensation when losses arise from the defect. This applies when, for example, a production environment failure causes lost sales. The contractor's attributable fault is required.

4. Right to Cancel the Contract (Civil Code Articles 564, 541 et seq.)

The right to cancel the contract when a serious defect makes it impossible to achieve the contract's purpose. Cancellation generally requires prior notice, and when cancellation is recognized, an obligation may arise to return compensation already received.

Practical Procedure for Exercising Rights

Step 1: Early Issuance of Notification

Upon discovering a defect, notify the contractor in writing without delay. Since the one-year clock under Civil Code Article 566 begins from "when you knew," notification in a form that leaves a record is important. The notification should specifically describe the content of the defect, circumstances of occurrence, and scope of impact.

Step 2: Demand for Repair with Notice

When demanding repair, give adequate time by stating "please make the correction by [date]." The length of time should be set according to the complexity of the defect, but one to two weeks is generally a reasonable standard.

Step 3: Confirming Refusal or Non-Performance

If repairs are not made after the notice period expires, or if the contractor refuses to repair, consider transitioning to price reduction, damages, or contract cancellation. At this stage, sending a written notice (certified mail) is effective as a legal response.

Step 4: Preserving Funds

If there is an outstanding balance, withholding payment "until the defect is corrected" is a realistic option. However, since there is risk of receiving a payment demand from the contractor if the grounds for withholding are unclear, it is recommended to consult an attorney before making this decision.

Common Mistakes Clients Make

Vague demands of "just fix it"

Issuing a demand to "fix everything because it's all defective" without organizing the content and scope of impact prolongs disputes with the contractor. To exercise rights effectively, it is important to specifically identify defects and communicate them in order of priority.

Delayed notification

The judgment "I'll tell them all at once later" creates a risk of impairing the notification period under Civil Code Article 566. The basic principle of rights preservation is to notify in writing at the point of discovery.

Taking free repair for granted

Not all defects discovered after acceptance completion are subject to free repair. Demands that exceed the contractor's free repair obligation lead to prolonged negotiations and relationship deterioration. Understanding the scope of legal obligations and making reasonable demands is ultimately the better approach for clients as well.

Contract Design to Reduce Defect Risk

This section presents contract clause designs for preventing defect disputes and facilitating smooth resolution when they do occur.

Contract Design Points for Contractors

Clarifying the Warranty Period

Instead of the Civil Code default (one year from when known), explicitly state the period as "X months after acceptance completion." For freelancers, "3 months after acceptance" is a fairly standard industry setting. However, when subject to the Freelance Protection Act, be aware that setting an extremely short period may be problematic.

Listing Exemptions

Specify in writing that the contractor's repair obligation does not arise in the following cases:

  • Operational defects in environments not listed in the supported environment list
  • Defects caused by modifications after delivery by the client or third parties
  • Issues related to functions and operations not specified in the specifications document
  • Issues caused by updates to external services or libraries after delivery

Specific Statement of Supported Environments

The description "latest versions of major browsers" is ambiguous. State specifically to the version level, such as "Chrome 128+ / Firefox 130+ / Safari 17+ / Edge 128+ (latest versions on macOS and Windows)."

Proposing a Paid Maintenance Contract

Propose that ongoing support after the warranty period ends be contracted separately as paid maintenance. Rather than "deliver and done," building a continuing relationship allows simultaneous stabilization of revenue and reduction of dispute risk.

Contract Checkpoints for Clients

Documenting the Acceptance Process

Specify in the contract "who" conducts acceptance, "by what criteria," and "within how many business days." If the acceptance procedure is ambiguous and there is no evidence of "acceptance completion," it later becomes a dispute point whether acceptance was truly completed.

Procedures for Defect Discovery

Define the notification method when defects are discovered (written notice, email, etc.) and the contractor's response deadline (within 3 business days, etc.). Clarifying the procedure reduces the risk of delays in repair response.

Handling Production Environment-Specific Risks

For issues that may arise from differences between test and production environments (data volume, load, integration service differences, etc.), clarify in advance the division of responsibility between what is verified in the acceptance environment and additional verification responsibilities in the production environment.

Common Practices for Both Parties

Version Control for Specifications

When specifications change, manage them with version numbers. Having "Final Specifications v2.3" exist and a record that both parties confirmed the same file makes the basis for the claim "I built it according to the specifications" clear.

Using Acceptance Checklists

List confirmation items for deliverables in advance and confirm them with both parties at acceptance. By making confirmed items explicit in writing, later claims of "we didn't confirm this part" are prevented.

Preserving Communication Records

Record all instructions, approvals, and change requests in email or chat. Develop the habit of always sending a confirmation email reply for any verbal agreements. Defect disputes tend to become "he said, she said" arguments, and written records serve as the strongest defense.

Disputes over deliverable defects can be significantly prevented through pre-contract design and record-keeping habits. Contractors accumulate evidence that they can say "I built it according to the specifications," while clients specifically identify what the problem is before exercising their rights. When both parties understand the legal grounds, constructive resolution based on facts and law — rather than emotional arguments — becomes possible.

Related Articles