How to Hire a Development Vendor in Japan

Companies from outside Japan sometimes ask me about getting software built here. Listening to them, the sticking point is almost always in the same place.

It is not technical. They are stuck on contract structure and team composition.

Japanese software procurement rests on a few assumptions that are hard to see from outside. Here is what they are.

There are three contract types

When you outsource development in Japan, the contract will effectively be one of three kinds.

• Ukeoi — a contract for a completed deliverable
• Jun-inin — a quasi-mandate contract for work performed
• SES / haken — dispatch, closer to renting a person by the month

These differ fundamentally in what you are actually buying.

Ukeoi buys a deliverable. You receive a finished system and formally accept it. You do not direct how the work is done, but if it is not finished, that is the vendor’s liability.

Jun-inin buys effort. There is no obligation to complete a deliverable. The vendor owes a duty of care — to work diligently as a professional — and nothing more.

SES is, in practice, close to engaging a person on a monthly basis. It is operated on the premise that direction and supervision remain with the vendor.

In Western terms, ukeoi is close to fixed-price and jun-inin is close to time and materials. What differs is where responsibility is cut.

Choose ukeoi and you cannot change requirements later

This is where things go wrong most often.

An ukeoi contract assumes the deliverable is defined at signing. If requirements change, additional cost and schedule follow as a matter of course.

If you bring a product-development instinct — deciding as you build — every one of those decisions becomes a contract amendment.

Choosing ukeoi before requirements are settled fails almost every time. And yet clients want ukeoi, because the price looks fixed.

It only looks fixed. It is not.

Start without acceptance criteria and you cannot finish

Ukeoi contracts include kenshu — formal acceptance. The client reviews the deliverable and judges whether it matches the contract.

If the criteria for that review are not documented at contract time, the project stalls near the end, arguing over whether the thing is finished.

A large share of the projects burning down in Japan are stuck here. Not on technical difficulty — on the absence of an agreement about acceptance.

What you need to fix in writing: operating conditions, target browsers, performance requirements, and the boundary between “fixing a defect” and “additional development.”

That last one carries the most weight.

Where 1,000,000 to 1,500,000 yen per month actually goes

A reference figure for rates — this is what the client pays, not what the engineer receives.

A mid-level engineer runs around 1,000,000 yen per person-month, roughly 6,700 USD at 150 yen to the dollar. A senior engineer runs around 1,500,000 yen, about 10,000 USD. That is a working baseline for development procurement in Japan.

But that figure rarely reaches the person doing the work in full.

Japanese software services run on layered subcontracting. A prime contractor wins the work, subcontracts to a second tier, which subcontracts to a third. Each layer takes a margin.

So even when you pay the full 1,500,000 yen senior rate, the person actually writing code may be receiving a fraction of it. Sometimes the person in that seat is not being paid at a mid-level rate either.

This is not a moral argument. It matters as a practical procurement problem.

You lose visibility into what level of engineer is actually working on your system relative to what you are paying.

Ask to see the team structure

So there are things to confirm before signing.

• Are the people who will build this employed by the company you are contracting with?
• If not, how many subcontracting layers are there?
• How many years of experience do those people have?

If they cannot answer, or would rather not, that is itself a data point.

One more. Check whether the people in your meetings are the same people writing the code.

It is common for the only English speaker to be a sales representative. In that case every technical decision passes through translation, and the details of the specification reliably fall out along the way.

How I would approach it

If I were procuring development in Japan from abroad, I would structure it this way.

Start with jun-inin while requirements are still unsettled. Spend the first month or two building and firming up requirements, then decide whether to move the remainder to ukeoi.

Write the acceptance criteria at the same time as the requirements. Do not defer it.

And put someone technical on your side of the table. If you do not have that person internally, bring one in.

That last point is the one that matters. The goal is not to manage the vendor. It is to have someone on your side who speaks the same language as the vendor.

Japanese vendors respond to technically sound requests. The problem is usually that the request never reaches them in a technically sound form.