What Is Lab-Type Development? When a Dedicated Team Fits, and How It Differs from Fixed-Price and Quasi-Mandate

"We get a quote for every project, and the team changes every time. Nobody left knows the earlier work." "We want to hire our own engineers, but that will take a while, and development cannot stop in the meantime." We hear this more and more from companies that run a service and keep improving it.

Lab-type development (ラボ型開発) is a dedicated team that you reserve for a period and pay monthly. Unlike fixed-price (ukeoi) development, which is contracted project by project, the same team stays on your work. Knowledge builds up, and priorities can change as you go. In return, deciding what to build stays with you, the client.

This article explains what lab-type development is, how it differs from a fixed-price contract and a one-off quasi-mandate contract, its advantages and drawbacks, the projects it suits, and what to decide before you start.

What lab-type development is

Lab-type development is not a legal term. It is an industry name for one way of structuring a contract with a development company. The development company sets up a team (the "lab") that works only for you, and you reserve it for a period such as six months or a year at a monthly fee. During that period the team handles your development and nothing else.

In most cases the contract itself is a quasi-mandate contract (jun-inin, a time-and-materials style contract under Article 656 of the Civil Code), where you pay for the work performed. A fixed-price contract (ukeoi, a contract for the completion of work under Article 632 of the Civil Code) promises to complete an agreed deliverable. Under a quasi-mandate contract, you can change what the team builds during the period. We explain the contract itself in What Is a Quasi-Mandate Contract?.

The model first spread through offshore development, which uses development bases abroad, but development companies in Japan use the same structure. We form our teams from our development base in Nepal and a project manager in Japan, and handle ongoing development this way.

How it differs from fixed-price development and a one-off quasi-mandate contract

Fixed-price development suits projects where what to build is already decided. The total cost and the deadline are fixed first, and the development company takes responsibility for completion. See What Is Fixed-Price (Ukeoi) Development? for details.

A one-off quasi-mandate contract suits work with a set period, such as requirements definition or a study. The easiest way to think of lab-type development is as that quasi-mandate contract continued with the same team.

Advantages of lab-type development

• Knowledge stays with the team. The people who know the business background, past decisions and the quirks of the code keep working on it. You no longer spend time explaining everything again for each project.
• You can change priorities. You can swap what gets built next to match user feedback and the state of the business. There is no back-and-forth over additional quotes.
• You get a team without hiring. You secure a dedicated team without recruiting and training in-house. You can also run it alongside your own engineer hiring.
• Small improvements keep flowing. Minor fixes that rarely fit into a fixed-price quote are handled one by one within the month.

Drawbacks of lab-type development

• You pay even when there is no work. The contract reserves the team, so the monthly fee continues even if requests dry up. Unless there is always a next job, it becomes expensive.
• Nobody is responsible for completion. Because the base is a quasi-mandate contract, there is no promise that an agreed item will be finished by an agreed date. It does not suit deliverables with a fixed deadline.
• You have to stay involved. You decide the priority of what gets built. If nobody in your company can make that call, the team spends more time waiting.
• It takes time to get going. The few weeks the team needs to understand your business are a period with little visible output. In a short contract, that period weighs heavily.

Projects that suit lab-type development, and those that do not

It suits development that has no end. Typical cases are continuous improvement of your own service, a plan to build an internal business system piece by piece, and the stage after launching a minimum viable product (MVP), when you change features based on how users respond.

It does not suit projects you build once and finish. Migrating an existing system, building a system whose specification is already fixed, or a one-off development that completes in a few months is clearer for both sides as a fixed-price contract with an agreed total.

If you are unsure, one approach is to build the first version under a fixed-price contract and switch to lab-type development for the improvements after launch.

How lab-type development runs

• Start-up. In the first few weeks the team learns your business and your system. This is when existing code and documents are handed over, the development environment is set up, and the way you will communicate is decided.
• Building the work list. You list what you want done in a backlog, and the person in charge on your side sets the priorities. Not everything needs detail; only the next items are made specific.
• Development in short cycles. In cycles of one or two weeks, the team builds the highest-priority items and you review them. At the end of each cycle you look at working software and reset the priorities.
• Review and adjustment. Each month you check the hours spent and the results, and at the contract review point you decide on team size and whether to continue.

Cost is set by the team size and the period. The monthly fee usually covers the engineers' time, the involvement of a project manager or team leader, and the tools used to work together. Cloud fees and external services are charged separately. Think of it not as a fixed-price total but as the monthly fee multiplied by the period, and put review points partway through the period.

What to decide before you start

• The person in charge on your side. Choose one person who gives the team its priorities and makes the acceptance decisions. In agile development this role is called the product owner.
• The period and review points. Set the contract period, such as six months or a year, and the points at which you review team size and continuation. Agree the exit conditions in advance too.
• Team stability and replacement rules. Confirm who joins the team and how handover works when a member has to be replaced.
• How instructions are given. If you directly instruct the development company's engineers on how to do their work or on their working hours, this may count as disguised contracting (giso ukeoi) and violate the Worker Dispatch Act. The Q&A collection of the MHLW (Ministry of Health, Labour and Welfare) says it is not disguised contracting when the client and the contractor work together as equals and the contractor makes its own decisions. Pass requests through the person in charge, and leave decisions on how to do the work with the team.
• How work is made visible. Decide which tools you will use to share weekly reports, the list of remaining work and the breakdown of hours spent.
• Ownership of deliverables and code. Confirm who holds the copyright to the code and design documents, and how they are handed over when the contract ends.

This is a general overview. For an individual contract, please rely on the contract wording and, where needed, a professional's review.

How we run lab-type development

We form a dedicated team from engineers at our development base in Nepal and a project manager in Japan. The project manager in Japan organises requirements with the person in charge on your side, and the team repeats short cycles of development and review. Progress, remaining work and hours spent are shown to you as they are, in our own project-management tool.

Many of our projects start with a fixed-price build and switch to lab-type development for the improvements after launch. Which form fits depends on whether the development ends after one release or continues.

FAQ

Are lab-type development and a quasi-mandate contract the same thing?

No. A quasi-mandate is a form of contract; lab-type development is a way of organising a team. Most lab-type development is contracted as a quasi-mandate, but quasi-mandate contracts also cover one-off work such as support for requirements definition.

What is the shortest contract period?

It depends on the development company, but because a team takes a few weeks to get up to speed, about six months is typical. For shorter work, a one-off quasi-mandate or a fixed-price contract is often a better fit.

Can we change the team size partway through?

Under most contracts, yes, at the review points. Adding people at short notice takes time to arrange, so agree the review points and the notice period when you sign.

Can you commit to a deadline in lab-type development?

Because the base is a quasi-mandate contract, there is no promise of completion. However, a feature with a fixed date can be carved out as a separate fixed-price contract, so a combination is possible.

Can we work in Japanese with a team abroad?

It depends on the development company. At wesionaryTEAM, a project manager in Japan is your contact and handles requirements and day-to-day communication in Japanese.

Summary

Lab-type development reserves a dedicated team for a period and keeps developing while priorities change. Knowledge builds up and small improvements keep flowing, but you pay even when there is no work, and you must keep deciding what to build.

The basic rule is lab-type development for work that continues and a fixed-price contract for work that ends after one release. To see which your project is, book a free estimate consultation and your project manager will work out the team size and a cost range with you.

Related articles and pages

• What Is Fixed-Price (Ukeoi) Development? Pros, Cons and How It Differs from Quasi-Mandate Contracts
• What Is a Quasi-Mandate Contract? When to Use It in System Development and How It Differs from Fixed-Price
• What Is Contract Development? Contract Types and What to Decide Before You Order
• PoC vs MVP: What Is the Difference? Purpose, Timeline and Process Compared
• What Is MVP Development? Process, Cost and How It Differs from a PoC
• Should You Insource or Outsource System Development?
• Free estimate consultation: discuss scope and a cost range with a project manager

Sources

• e-Gov Law Search, "Civil Code (Act No. 89 of 1896)", Articles 632 and 656 (in Japanese)
• MHLW, "Q&A collection on the criteria distinguishing worker dispatch from contracting (Notice No. 37)", updated 25 May 2026, Collection 3, Q1 and Q2 (in Japanese)
• IPA, "Model Transaction Contract for Information Systems (Agile Development Edition)", 31 March 2020 (in Japanese)