Article Categories

All Articles

Soft Skills

Organizational Culture

Technology

BLOG

What Building Through Co-Creation Means: How Development Changes When You Stop Being Client and Vendor

November 4, 2026

Organizational Culture

We often use the phrase "building through co-creation". Our vision is "toward a society where co-creation is the norm". From the outside, though, it is hard to tell what the phrase means on a real project. It is not a dialogue programme of the kind large companies run, and it is not joint development where cost and intellectual property are shared.

In one sentence: it means dropping the relationship of a client who orders and a vendor who delivers. We call this co-creation development. Every week, the client and we look at a running version in the same meeting, decide priorities and specifications together on the spot, and keep shipping working software. Once that relationship goes, the way decisions are made, the way responsibility is held, and what we ask of the client all change.

This article describes those changes concretely. It covers not only the upside but the burden we ask the client to carry, and the cases where it does not fit. The founding story is in why we founded wesionaryTEAM, so here we focus on how the way of working differs.

Drop the client-and-vendor roles: decisions are not made in separate rooms

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 tends to happen in contract development

Contract development, that is fixed-scope outsourcing, proceeds like this: define the requirements, agree a quote and a contract, the development company builds, and it delivers. If the requirements are fixed and will not change, this is a sensible way to work.

The problem is that requirements are rarely fixed from the start. There are always things you only learn by using the system. But in the contract form, the client cannot see much of what is being built, and the mismatch appears near delivery as "this is not what I expected".

This is not only our impression. In the fiscal 2025 survey by the Japan Users Association of Information Systems (JUAS), the three factors below were again the most cited reasons for projects missing their schedule.

Reason the schedule was missed	Share of companies citing it (multiple answers)
Insufficient consideration at planning	52.5%
Current operations and systems more complex than expected	48.8%
Frequent specification changes	42.4%

In the same survey, 57.4 to 69.0% of companies named requirements definition as the phase that hurt quality, budget or schedule. On large projects of 500 person-months or more, 47.8% missed their schedule. Requirements move even when they were meant to be fixed. That is the state of the industry, not of one company.

The Ministry of Economy, Trade and Industry's DX Report makes the same point about leaving development to a vendor without clear requirements: the finished system differs from what the client intended, large rework appears in testing, costs overrun, delivery slips, and blame is pushed back and forth. It concludes that the client, not the vendor, must be the one who fixes the requirements.

And change becomes negotiation: a conversation about extra cost and deadlines, and about whose fault it is. Nobody is at fault. The client-and-vendor relationship makes it happen, because a vendor paid a fixed price has a reason to hold back additions and changes. The government's model contract for agile development says exactly that about fixed-price contracts, and assumes a time-and-materials contract instead, where the client pays for the work rather than for a fixed deliverable.

How the work proceeds: contract development and co-creation

What changes under co-creation

Three things change.

Decisions are not made in separate rooms. Every week, the client and we look at a running version in the same meeting and decide on the spot. There is no division into a client who decides and a vendor who executes.
Priorities are set together. Instead of deciding everything up front, we choose what to build next each time. A feature that turns out to be unnecessary is not built.
Change is assumed. It is expected, not negotiated. We build small, try it, fix it and repeat.

The weekly meeting covers three things: trying what was shipped last week, reordering priorities and trimming scope, and deciding what ships next week. Decisions are recorded there and then in a project management system the client sees on the same screen, so there is no "I said, you said" later.

We also draw the line of responsibility. The client decides what to build and in what order. We are responsible for what was decided arriving as working software of proper quality. The government's model contract takes the same view: the person responsible for ordering what gets built, the product owner, is appointed by the client, and that role should not be handed to the development company. Our rule of "send someone who can decide on the spot" is that principle put into practice.

We call this way of working "in-house co-creation": framing the problem with design thinking, testing small with the lean startup approach, and iterating with agile development. It means working as if we were part of the client's own team.

What we ask of the client

Co-creation does not reduce the client's burden. The time involved is, if anything, greater than in contract work. We ask for three things.

Time

Attend a weekly meeting. It is where the running version is seen and decisions are made. In addition, answer the questions we raise during the week without waiting for the next meeting. When replies stop between meetings, that week's development stops with them.

Decisions

Send someone who can decide on the spot. If decisions go back for internal approval, the speed of iteration is lost. Companies with formal approval processes can still work this way if the decision-maker agrees in advance what may be decided in the meeting.

Ownership

Let the actual users try it. The contact person alone cannot tell where users hesitate. Part of each meeting is set aside for users to try the system.

If these three cannot be provided, co-creation does not work well. In that case, the contract form is the better fit.

When the decision-maker can no longer attend

Abstracting the cases that did not go well, most began with the decision-maker no longer being able to attend the weekly meeting. Decisions went back for approval, iteration stopped, and the same waiting as in contract work appeared.

When we see that happening, we propose switching to the contract form: fix the remaining scope, agree a new quote and contract, and work towards delivery. We do not keep co-creation going by force. The trigger for the switch is not whether the scope has settled but whether the decision-maker can be in the room every week.

Where it does not work, and who it suits

Where co-creation fits and where contract work fits

Co-creation suits the stage where what to build is still being worked out, such as a new business or rebuilding a process. It works best when users' feedback should shape the product, a decision-maker can join every week, and the client wants to keep growing the system in-house.

It does not suit cases where the requirements are fixed and will not change, where the decision-maker cannot take part and only a contact person is available, where the deadline and scope are fixed with no room to change, or where the client wants to hand everything over without involvement along the way. We take such projects on in the contract form.

A word on terms. Our co-creation is not joint development, where cost and intellectual property are shared. It is not an ideation workshop either. It is shipping working software every week and deciding together, every week, on what we see.

How it takes shape as a service

This way of working runs through our services: PoC and MVP development, which tests a new business in its smallest form; product co-creation, which grows a product within an existing business; and in-house development support, which brings the client's own team to the point of running on its own. Projects whose scope is already decided run as system development in the contract form. Compare the options under services, and we decide the fit together in the first conversation.

In-house development support is co-creation carried forward. The habit of deciding together in the same room every week becomes the client's own team's way of working. According to the Information-technology Promotion Agency's DX Trends 2025, fewer than one in ten Japanese companies have fully adopted agile principles in any department. That is why we start by building the way of working together. The criteria for insourcing versus outsourcing are in a separate article.

FAQ

What are the drawbacks of co-creation development?

Three. The client spends more time than in contract work, the total cost is not fixed at the start, and progress stops if the decision-maker can no longer attend the weekly meeting. Whether you can carry these three is what decides the fit.

With co-creation, are cost and scope left undecided?

The ceiling is set by the period and the team; the scope is the result of the priorities. We fix the period and the team first and choose together, every week, what to build within them. Because the scope is not fixed, a time-and-materials contract fits better than a fixed-price one. For new-business launches and AI adoption we sometimes charge nothing until launch and are paid from results afterwards. We propose the form of the fee in the first conversation.

Can a company that needs formal approval still work this way?

Yes. The condition is that someone with decision authority attends the weekly meeting. If the decision-maker agrees in advance what may be decided in the meeting, no case-by-case approval is needed. Where that is not possible, we propose the contract form.

Can we co-create without engineers of our own?

Yes. What is needed is not engineers but someone who can decide and the people who will actually use the system. We provide the technology; we ask the client for decisions and knowledge of the work.

Do you not take contract development?

We do. Fixed requirements with no room to change suit the contract form. Which fits better is something we judge together in the first conversation.

Summary

Building through co-creation means dropping the client-and-vendor relationship and not making decisions in separate rooms. Priorities are set together, and the system is built small and reshaped on the assumption that it will change. In return, we ask the client for time, decisions and ownership.

It fits some situations and not others. If you want to start by judging the fit together, book a free estimate consultation with one of our project managers. In either form, co-creation or contract, you get an outline of scope and cost in that conversation. If you would rather discuss the way of working first, contact us. Real projects are in our case studies.

Development Consultations and Estimates

As your co-creation partner, we drive business development and DX.

We start with a call with your project manager to confirm what to build and the expected cost range.