BLOG

What Is Fixed-Price (Ukeoi) Development? Pros, Cons and How It Differs from Quasi-Mandate Contracts

"The contract from the development company says ukeoi. How is that different from contract development?" "We thought a fixed-price contract meant we could leave everything to the vendor, but then we were told that added features cost extra." We often hear questions like these from people ordering system development from an outside company for the first time.

Fixed-price (ukeoi) development is development carried out under a contract that pays for the completion of work. The total price and the delivery date are fixed up front, which is reassuring. But unless you define what "complete" means when you sign, disputes over extra charges and acceptance are easy to fall into.

This article explains what fixed-price (ukeoi) development is, how it differs from contract development, quasi-mandate contracts and SES, its pros and cons, which projects suit it, and what to decide before you sign. We write from the viewpoint of a company that develops under both fixed-price and quasi-mandate contracts.

Fixed-price development pays for the completed deliverable, while a quasi-mandate contract pays per period for the work performed; the basic rule is to use fixed-price only for the parts whose specification is settled.

About the author

wesionaryTEAM Editorial Team

The editorial team is made up of wesionaryTEAM's project managers and engineers. Drawing on what we learn every day on business system, AI adoption and digital transformation projects, we publish information people can use when making decisions, with cases and figures.

What fixed-price (ukeoi) development is

Fixed-price (ukeoi) development means developing a system or software under a fixed-price contract (ukeoi, 請負契約), a contract for the completion of work under Article 632 of the Civil Code. Article 632 defines it as a contract in which one party promises to complete a piece of work and the other party promises to pay for the result of that work. The development company is obliged to complete the agreed deliverable, and the client pays for the result.

What is paid for is the result of the work, not the hours spent. If development takes longer than expected, the contract price does not change as a rule. Conversely, if the agreed deliverable is not completed, the development company cannot claim payment as a rule. (If the contract is cancelled before completion, Article 634 allows payment in proportion to the part from which the client benefits.)

Contract development (受託開発, jutaku kaihatsu) and fixed-price development are easy to confuse. Contract development is the general term for having an outside company develop a system; it does not say which type of contract is used. If that contract is a fixed-price contract, it is fixed-price development; if it is a quasi-mandate contract, it is contract development under a quasi-mandate. In other words, fixed-price development is one contract form within contract development. We cover contract development itself in What Is Contract Development?.

How it differs from quasi-mandate, SES and worker dispatch

Besides fixed-price, there are two other contract types for outsourcing development: the quasi-mandate contract (jun-inin, a time-and-materials style contract) and worker dispatch. SES (system engineering service) is in most cases concluded as a quasi-mandate contract.

Fixed-priceQuasi-mandateWorker dispatch
What is paid forCompletion of the workPerformance of the workWorking hours
Responsible for completionYesNoNo
Who directs the engineersDevelopment companyDevelopment companyClient

A quasi-mandate contract pays for the performance of the work itself, and completion of a deliverable is not promised. Under Article 644 of the Civil Code, the contractor must perform the work with the care of a prudent manager (a duty of care). See What Is a Quasi-Mandate Contract? for details.

Under worker dispatch, the client can give instructions directly to the dispatched engineers. Under fixed-price and quasi-mandate contracts, the development company directs its own staff. If the client directly tells the development company's employees how to work or what hours to work, this may be disguised contracting (giso ukeoi), which violates the Worker Dispatch Act. The distinction is judged on the actual situation under MHLW (Ministry of Health, Labour and Welfare) Notice No. 37, not on the name of the contract.

Advantages of fixed-price development

  • The total price and delivery date are fixed first. Budget approval is easier and internal planning is simpler.
  • The development company is responsible for completion. As a rule, it bears the cost if the work takes longer than expected.
  • The development company is liable for defects after delivery. If the deliverable does not conform to the contract, the client can demand cure such as repair, a price reduction, damages, or cancellation of the contract (Articles 559 and 562 to 564 of the Civil Code).
  • The client's day-to-day burden is small. Decisions on how to proceed are left to the development company, so the client can focus on requirements definition and acceptance.

Disadvantages of fixed-price development

  • The specification must be settled first. Without a definition of what counts as complete, no fixed price can be quoted. If you ask for a total price before the requirements are settled, the development company will either add a risk premium or interpret the scope narrowly.
  • Changes mean an additional contract. Any change beyond the agreed scope means a new estimate and a new contract. It is a poor fit for projects where you want to change the specification as you use the system.
  • Stopping midway leaves a cost. Under Article 641 of the Civil Code, the client may cancel the contract at any time before completion, but must compensate the development company for its loss.
  • You cannot direct the engineers yourself. Decisions on how to proceed rest with the development company, so you cannot pass small daily requests straight to the engineers. You need to agree a point of contact and a change procedure.

Projects that suit fixed-price development, and projects that do not

Fixed-price suits projects where what to build is already decided. Typical examples are migrating or rebuilding an existing system, a business system that already has a specification, and the design and development phases after requirements definition is complete.

It does not suit projects where you decide as you build. The first product of a new business, a proof of concept (PoC) or a minimum viable product (MVP), and development that changes features based on user feedback fit better with a quasi-mandate contract or lab-type development (a dedicated team).

In practice, a common approach is to run requirements definition under a quasi-mandate contract and then contract the development phase at a fixed price once the specification is settled. The Model Transactions and Contracts for Information Systems published by METI and IPA (Information-technology Promotion Agency, Japan) also takes this form of multi-stage contracting, with a contract for each phase.

How fixed-price development proceeds

Fixed-price development generally proceeds in the following order.

  • Requirements definition. Decide what to build. This phase is done under a quasi-mandate contract or in-house by the client.
  • Estimate and contract. Based on the settled requirements, the scope of deliverables, price, delivery date and acceptance conditions are written into the contract.
  • Design and development. The development company decides how to proceed. The client checks progress and decisions at weekly meetings or similar.
  • Testing and delivery. The system is delivered after the development company's own testing, and the client performs acceptance.
  • Maintenance after launch. Bug fixes and small improvements continue under a separate contract, usually a quasi-mandate.

What determines a fixed price is the number of screens and features, connections to external systems, whether data migration is needed, the devices to support, and how uncertain the requirements are. Even when you think you have asked for the same thing, prices vary widely when companies include different phases and allow differently for uncertainty. Align these assumptions first when comparing estimates.

What to decide before signing a fixed-price contract

  • The definition of complete. Write down what must be in place for the work to count as complete: the list of screens and features, the devices and browsers to support, and the performance conditions. If this is left vague, opinions will split at the acceptance stage.
  • The acceptance procedure and deadline. Decide how many days after delivery you will check the deliverable and how you will respond. Completion of acceptance affects when payment is due and when the period of liability for non-conformity starts.
  • How changes are handled. Decide who handles additions or changes to the specification, by what procedure, and how they are reflected in the price and delivery date.
  • The period of liability for non-conformity. Under Article 637 of the Civil Code, the client must notify the contractor within one year of becoming aware of a non-conformity. Contracts often set this differently, so check the period and when it starts.
  • Copyright and the scope of deliverables. Check who owns the source code and design documents, and whether you may modify them in-house after delivery. This matters especially if you plan to bring development in-house later.

This is a general overview. For individual contracts, please check the wording of the contract and consult a specialist where needed.

FAQ

Do fixed-price development and contract development mean the same thing?

No. Contract development is the general term for having an outside company develop a system; fixed-price development is the part of it done under a fixed-price contract. Contract development is also done under quasi-mandate contracts.

With a fixed-price contract, are specification changes handled free of charge?

Fixes within the agreed scope are covered, but additions or changes beyond it generally require an additional contract. If you expect changes, agree the procedure for them when you sign.

What happens if a defect is found after delivery?

If the deliverable does not conform to the contract, you can demand cure such as repair. The Civil Code requires notice within one year of becoming aware of the non-conformity, and contracts may set a different period.

Can we check progress during fixed-price development?

Yes. Weekly meetings and interim reviews are usually built into the contract or the way of working. Giving work instructions directly to the engineers may count as disguised contracting, however, so go through the agreed point of contact.

Which is cheaper, fixed-price or quasi-mandate?

There is no general answer. If the specification is settled, a fixed-price contract fixes the total; if it is not, the fixed price will include a risk premium. Splitting by phase, quasi-mandate while you are still exploring and fixed-price once things are settled, is the sensible choice on cost as well.

Summary

Fixed-price (ukeoi) development is a contract that pays for the completion of work. The total price and delivery date are fixed up front, and the development company is responsible for completion and for defects. In return, you must define what counts as complete before you start, and changes mean additional contracts.

The basic rule is to use fixed-price when what to build is decided and quasi-mandate when you decide as you build, splitting by phase. Even if you are not sure which fits, your project manager will work through the scope and the contract type with you in a free estimate consultation.

Related articles and pages

Sources

Reviewed by

Ichiro NagataCEO and Representative Director

A former engineer at Yahoo! JAPAN. For more than 18 years at startups and large companies, he has worked on a wide range of projects, from new consumer and business ventures to the digital transformation of operations. Alongside hands-on development as an engineer, he has built and managed teams, designed businesses and tested hypotheses, gaining broad experience in launching and growing businesses. He has been through three business sales. Convinced that co-creation makes products better and lets ideas be tested in the market, he founded wesionaryTEAM to offer a co-creation platform.