What Is Contract Development? Contract Types and What to Decide Before You Order

"We decided to outsource our system development, but one company's contract said 'fixed-price' and another's said 'time-and-materials.' What is the difference?"

"We asked development companies for estimates, and the amounts differed by several times. We thought we had asked for the same thing."

"What was delivered was not what we expected. We were told it wasn't in the specifications."

Conversations about outsourcing system development often start with comments like these. Each one comes from a mismatch in understanding: about the form of the contract, and about what needed to be decided.

In this article, we explain what contract development is, how it differs from other ways of getting work done, what changes with the form of the contract, and what you should decide before placing an order, from the perspective of a company that does contract development.

What Is Contract Development?

Contract development is an arrangement in which you ask an outside company to develop a system or software and pay for the delivery of the finished deliverable. The company that takes on the work handles everything from organizing requirements through design, development, testing, and delivery.

The defining features of this arrangement are that you can move development forward without employing engineers in-house, and that responsibility for the deliverable is clearly assigned.

A similar phrase is "outsourcing system development," but that is a general term for handing work to an outside party and does not specify the form of the contract. Contract development is one form within it.

How It Differs from SES, Staffing, and In-House Development

There are several ways to rely on outside help, and they are easily confused, so let's sort them out.

SES (System Engineering Service) is paid on the basis of engineers' working hours. It is a contract to supplement your workforce, and it does not promise a completed deliverable. Both may be called "outsourcing," but responsibility sits in completely different places in contract development and SES.

Staffing (worker dispatch) differs from SES in that the client can give instructions directly. Under SES, the client cannot direct the engineers directly, and doing so creates a contractual problem.

In-house development means building your own products and services with your own staff. Bringing development in-house is the effort to move closer to this form.

When you compare estimates, first make sure you know which form each proposal is based on. A contract for time and a contract for a deliverable mean fundamentally different things by their price.

What Changes Between a Fixed-Price Contract and a Time-and-Materials Contract

Contract development is usually done under one of these two. Here is what changes in practice.

Lining them up across four points makes the differences clear.

A fixed-price contract (請負契約) pays for the completion of the work. If the agreed deliverable is not completed, the company cannot claim payment. If, after delivery, parts are found that do not conform to the contract, the development company is responsible for fixing them. This is called liability for non-conformity with the contract (契約不適合責任).

Before the amendment of Japan's Civil Code in April 2020, this was called "warranty against defects" (瑕疵担保責任). Older documents and articles still use that term, so you need to read it as the same concept.

A time-and-materials (quasi-mandate) contract (準委任契約) pays for the performance of the work. The company is required to carry out the agreed work properly, but the completion of a deliverable itself is not promised.

A worker dispatch contract differs from the two above in that the client can give instructions directly. Under fixed-price and time-and-materials contracts, the authority to direct the work lies with the development company, so if the client gives instructions directly to the engineers on the ground, it creates a contractual problem.

In practice, the differences show up as follows.

• Are the specifications settled? If what you are building is clear, a fixed-price contract fits. At a stage where you are exploring requirements as you go, a time-and-materials contract fits reality better
• Handling changes. Under a fixed-price contract, changes beyond the agreed scope require an additional contract. Under a time-and-materials contract, you can move forward while reshuffling priorities
• Deciding when it is complete. A fixed-price contract needs acceptance criteria. You need to write down at the time of contracting what must be working for the work to be considered complete

A common approach is to split the contract by phase: time-and-materials for requirements definition, and fixed-price for development once the specifications are settled. Trying to fix everything under a fixed-price contract from the start means putting a price on things that have not been decided, which works against both sides.

When uncertainty has to be turned into a price, a development company has only two options: add a margin for the risk, or interpret the scope narrowly. The first means the client pays extra; the second leads to exchanges like "that's out of scope." Trying to fix a total price before the requirements are settled leads to one or the other.

Contracting requirements definition separately may look like a detour, but it gets you there faster in the end. Once what to build has been decided, the estimates that follow become more accurate too.

Note that this explanation is a general overview. For the details of an individual contract, please check the wording of the contract itself and, where necessary, have a professional review it.

Advantages of Contract Development

You can start without hiring. You can begin development without the time and cost of recruiting and training engineers.

You can use specialized skills for just the period you need them. You can secure people with deep knowledge of specific technologies only for the time you need them. You don't have to keep them on staff permanently.

Someone takes responsibility for the deliverable. Under a fixed-price contract, the development company bears the responsibility if the work is not completed.

No added burden inside your company. You avoid piling development work on top of people who already have their own jobs.

It can be built around your operations. Even for work that off-the-shelf products don't fit, you can build something that matches the way your company works.

Disadvantages of Contract Development

Know-how tends not to stay in-house. The reasons behind design decisions and the practical knowledge of how to run the system accumulate on the development company's side. You tend to end up outsourcing the next round of changes too.

Every change takes time. Each change involves a round trip of estimate, agreement, and kickoff. The more often a system changes, the more this waiting time adds up.

You have to hand information to an outside party. You share details of your operations and customer data with the contractor. You need agreements on how it is handled.

Misunderstandings happen easily. If something is built without the business side's intent getting fully across, the result works but doesn't get used. The "not what we expected" at the start of this article is exactly this.

Initial costs come in a lump. Rather than being spread out as personnel costs, as with in-house development, costs arise per project.

When Contract Development Fits, and When It Doesn't

When It Fits

• You have no engineers in-house who can develop it, or no realistic prospect of hiring them
• There is a fixed deadline, and no time to start from hiring
• The system, once built, won't change significantly for a while
• Off-the-shelf products don't fit your operations, and it needs to be built around your company
• The area is highly specialized, such as authentication or infrastructure, and there is little value in maintaining it yourself

When It Doesn't Fit

• The specifications change several times a month. The waiting time for each round trip ends up setting the pace of your business
• The system itself is what differentiates your business. Know-how keeps building up outside your company
• You haven't yet decided what to build. At this stage, starting with an approach that decides what to build will get you further faster

If the third point applies, an approach that builds something small to test it, like PoC/MVP development, is a better fit than ordering full-scale development right away.

If you are torn between contract development and bringing development in-house, we have laid out the decision criteria in Should you bring system development in-house or outsource it? Please read it as well.

The Contract Development Process

The names differ from company to company, but the work generally goes through the following phases.

1. Consultation and hearing — You share what you want to solve and by when you need it. At this stage, it is normal for the requirements not to be settled yet.

2. Requirements definition — You decide what to build. This is the most important phase. If you move on while things are still vague, it affects every phase that follows.

3. Design — The screens, how data is held, and how the system integrates with external systems are decided.

4. Development — Implementation goes ahead. An approach where you regularly review something that works helps catch misunderstandings early.

5. Testing — In addition to checks by the development company, the client also tests the system against its real business flows. Skip this and problems appear after launch.

6. Delivery and operations — Decide who will handle inquiries and bug fixes after handover. Under a fixed-price contract, it is common to set a period during which the development company is responsible for fixing bugs found after delivery. Please confirm that period and its scope as well.

There are two broad ways to run the phases. Waterfall plans the phases in order from requirements definition onward, on the assumption that you don't go back to an earlier phase. It suits projects with settled specifications and immovable deadlines. Agile repeats short cycles of building and reviewing. It suits projects where requirements are explored as you go.

These correspond to contract forms: waterfall is often combined with a fixed-price contract, and agile with a time-and-materials contract. Neither one is better; you choose based on how much of what you are building has been decided.

The phases that most need the client's involvement are 2, requirements definition, and 5, testing. Whether you can set aside time for them has a major effect on the outcome. If you go in thinking you can hand everything over, you will usually get something different from what you expected.

Common Contract Development Failures and How to Avoid Them

Through the consultations we receive, we see the same patterns again and again.

The client doesn't take part in requirements definition. This is the "we don't understand the technical side, so we'll leave it to you" approach. The development company doesn't know your operations as well as you do. The result is something that works but that the people on the ground don't use. To avoid this, put someone who knows the operations in the requirements definition sessions. No technical knowledge is needed.

Too many people make decisions. Every stakeholder puts in requests and nobody cuts anything. The scope swells, and both schedule and cost grow. Name one person as the decision-maker and let that person make the calls.

Testing is left entirely to the development company. The development company's testing confirms that the system works according to the specifications. Whether it can be used in your real business flows can only be confirmed by you. Skip this and problems appear right after launch.

Launch is treated as the finish line. If you launch without deciding who takes inquiries and who fixes things, everything stalls there. Decide the operations setup together with the development plan.

Choosing on price alone. An estimate might be low because the company is efficient, or because the scope it covers is narrow. If you compare only the amounts without aligning the assumptions, additional costs will come later.

Not mentioning plans to bring development in-house later. Whether the system is meant to be handed over affects both the technology choices and the design. Let the company know as soon as it is a possibility. If you bring it up later, parts may need to be rebuilt.

None of these are really about the client's capabilities; they are problems of how the project is designed. They can be avoided by deciding things at the start.

How to Think About Cost and Schedule

Even in publicly available information, the cost of contract development varies widely. It ranges from a few hundred thousand yen for something small to well over tens of millions of yen for building a core business system, depending entirely on the project.

The Person-Month Rate

When you receive an estimate, you may see the unit "person-month." This approach takes the cost of one engineer working for one month as a unit rate and multiplies it by the number of people and the length of time needed to get the total.

The method is easy to understand, but there is a caveat. Person-months measure input, not the amount of output. Building the same feature might take one month for an experienced person and three months for someone less familiar with it. Compared in person-months, the latter looks more expensive.

When comparing estimates, look beyond the unit rate and check how many people are assumed to be involved for how many months, and what will be completed with that effort. A low unit rate makes no difference to the total if the effort is high.

Person-month rates also generally vary by role. Project managers, engineers, and designers have different rates, so asking for a breakdown shows you how the team is composed.

What Determines the Price

Rather than the price itself, understanding what drives the price is what lets you compare estimates. The main factors are as follows.

• The number of screens and features
• The types of users (only general users, or also administrators and approvers)
• Integration with external systems (payments, authentication, existing core systems, and so on)
• Whether existing data needs to be migrated
• The devices supported (web only, or smartphone apps as well)
• The level of availability and audit logging required
• The scope of operations and maintenance after launch

The "amounts differed by several times" at the start of this article usually comes from these assumptions differing between companies. Neither is being unreasonable; the scope they include is different. When comparing, align these assumptions before lining up the amounts.

The schedule depends on the scale and on how settled the requirements are. What is common to all projects is that the main thing that stretches the schedule is not the amount of implementation, but time spent waiting for specifications to be decided. What makes the difference is whether you can set up a way of working where you review something that works at least once a week and make decisions on the spot.

What is easily overlooked is the ongoing cost of operations: cloud usage fees, databases, fees for external services, and monitoring. These continue every month, separate from the development cost. If you budget only for development, you will come up short after launch.

The same goes for maintenance costs. Does it cover only bug fixes, or small improvements too? What are the support hours? This varies by contract, so please check it together with the development estimate.

What to Decide Before Placing an Order

These are items that make the rest of the project easier if you decide them before requesting estimates.

What counts as success. Delivering something that works is presumably not the goal. Put into words, in advance, what would need to happen for you to say the investment has paid off.

Who decides. Name one person to make decisions on the specifications. The more stakeholders there are, the slower the decisions.

The form of contract and how changes are handled. Fixed-price or time-and-materials? If a spec change occurs, does it trigger a new estimate, or is it absorbed within a certain range? Always put anything agreed verbally in writing. "You said / we never said that" disputes are the most common form of trouble in contract development.

What the estimate covers. Requirements organization, UI/UX design, testing, cloud costs, maintenance after launch. How much of this is included?

Acceptance criteria. List, feature by feature, what must be working for you to accept the work.

Who handles operations. Who receives inquiries after launch, and who makes the call when there is an outage?

Rights to the deliverables. Who owns the copyright to the source code? If there is a chance you will bring development in-house in the future, check this point in particular.

Whether you intend to bring development in-house in the future. Whether the system is meant to be handed over affects the technology choices, the design, and the level of detail in the documentation. If you mention it later, parts may need to be rebuilt.

Security and information handling. Which data will you hand over, where will it be stored, and who will be working on it? If personal or confidential information is involved, you need agreements separate from the contract.

These are all things you can decide internally before requesting estimates. If you ask several companies while they are undecided, each company will estimate on different assumptions, and you won't be able to compare them.

Through our system development service, we handle everything from requirements definition through design, development, and operations. Our past case studies are also available.

Frequently Asked Questions

What is the difference between contract development and SES?

In contract development, payment is made for the delivery of a finished deliverable, and the development company is responsible for that deliverable. In SES, payment is made for engineers' working hours, and completion of a deliverable is not promised. Both may simply be called "outsourcing," but responsibility sits in different places in the two.

Which should we choose, a fixed-price contract or a time-and-materials contract?

If what you are building is clearly decided, a fixed-price contract fits; at a stage where you are exploring requirements as you go, a time-and-materials contract fits reality better. A common approach is also to split by phase: time-and-materials for requirements definition, and fixed-price for development once the specifications are settled.

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

They are not the same, but they are not opposites either. Contract development refers to the whole practice of entrusting development to an outside company. If the contract is a fixed-price contract, it is "fixed-price development"; if it is a time-and-materials contract, it is "contract development under time-and-materials." In other words, fixed-price development is one of the contract forms of contract development. The difference lies in where responsibility sits: under a fixed-price contract, the development company bears responsibility for completion and liability for non-conformity, while under a time-and-materials contract, payment is made for the performance of the work. For details, see "What Changes Between a Fixed-Price Contract and a Time-and-Materials Contract" above.

Can we hand everything over and leave it to you?

No. The requirements definition and testing phases need the client's involvement. Only the client knows what the system is for, so if you hand these over, you end up with something different from what you expected.

Why do estimates differ so much between companies?

Because each company includes a different scope. Requirements organization, UI/UX design, testing, cloud costs, maintenance after launch: the amount changes a great deal depending on how much of this is included. Before lining up the amounts, align these assumptions and then compare.

Can we change the specifications partway through development?

It depends on the form of the contract. Under a fixed-price contract, changes beyond the agreed scope generally require an additional contract. Under a time-and-materials contract, you can move forward while reshuffling priorities. If you expect changes, decide how they will be handled at the time of contracting.

Will we receive the source code for the delivered system?

It depends on the contract. Ownership of the copyright is set out in the contract, so please confirm it when you place the order. It is a particularly important point if there is a chance you will bring development in-house in the future.

Which should we choose, contract development or bringing development in-house?

A realistic split is to keep in-house the parts that are core to your business and change frequently, and to outsource the parts that are highly specialized and change little. We have laid out the decision criteria in Should you bring system development in-house or outsource it?

Can we consult you even if we haven't decided what to build yet?

Yes, you can. At that stage, an approach that builds something small to test it is often a better fit than ordering full-scale development right away. Please tell us what you would like to sort out through our contact page.

Should we go with waterfall or agile?

Choose based on how much of what you are building has been decided. If the specifications are settled and the deadline can't move, waterfall fits; if you are exploring requirements as you go, agile fits. They also correspond to contract forms: the former is often combined with a fixed-price contract, and the latter with a time-and-materials contract.

How much of the client's time does development take?

It varies by phase. During requirements definition and testing, your involvement is needed, taking a few hours a week or more depending on the scale. During design and development, a weekly review is enough to keep things moving. An approach that "takes none of your time" ends up producing something different from what you expected.

How much does maintenance after launch cover?

It varies by contract. Some cover only bug fixes, some include small improvements, and some specify support hours. Please check the scope and cost together with the development estimate. Cloud costs for operations also arise every month, separate from the development cost.

When getting estimates from several companies, what should we align?

The scope of what is being built (number of screens, features, external integrations, data migration, supported devices), the form of contract, the phases included in the estimate, and the scope of maintenance after launch. Give every company the same conditions on these four points. If they are not aligned, you can't tell where the difference in price comes from.

Summary

Contract development is a form of development in which you pay for the delivery of a finished deliverable. It differs from SES and staffing in both where responsibility sits and who directs the work.

The forms of contract are fixed-price and time-and-materials, and which one fits depends on whether the specifications are settled. Splitting the contract by phase is also common.

And contract development is not something you can simply hand over and forget. In the requirements definition and testing phases, the client's involvement determines the outcome. Before placing an order, make sure you can set up a team that can set aside time for these phases.