Article Categories

All Articles

Soft Skills

Organizational Culture

Technology

BLOG

Can a System Another Vendor Started Be Taken Over? A Real Restart After an Order One Digit Higher

November 12, 2026

Technology

A company came to us about a system development project that was already under way. They had placed the order with a well-known development company, and they were unhappy with the cost, the progress and the communication.

We take over development that another company has left partway. Here too, we reviewed the materials and deliverables, submitted an estimate, sorted what could be kept from what had to be rebuilt, and restarted the development. Our estimate was one digit smaller than the first company's.

This article uses what actually happened on that project to explain why the size of an estimate does not guarantee what you get, how we handle a takeover partway through, and what a buyer should check in the estimate and the contract. The industry and the amounts are withheld so that neither the client nor the first company can be identified.

The earlier deliverables sorted into what we kept (flow diagrams, expected scale, supported environments) and what we rebuilt (requirements, prototype, verification plan), with the estimate following

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.

We read everything and sorted what to keep from what to rebuild

We received a 21-page requirements document, a working prototype and a set of business flow diagrams. The prototype's screens all worked, and at first glance it looked close to finished. It appeared to have been produced in a short time by leaving the work to AI.

After signing the contract, we read every item and compared it against our own feature list. Some of it could be kept. We mapped the 31 business flow diagrams to our features one by one and used them to confirm requirements. Assumptions such as the expected number of users and the supported environments also carried over as the starting point for confirmation. What the client had already thought through and decided was not wasted.

The requirements document and the prototype, on the other hand, we decided to rebuild. The prototype was at a low level of completion, and the requirements document was hard to use even as a reference. Even an order priced one digit higher had not reached a level usable as a foundation for development.

What was missing was the part you cannot see by running it

The comparison showed three things.

No source for the details. The requirements document left the details of each process to the flow diagrams. Yet 17 of the 40 features on our list had no matching diagram.
No record of what was decided. The requirements document was still a draft. The sheet recording which features had been approved for development had not reached us three weeks after we started checking.
No plan for verification. Third-party vulnerability testing, load testing and disaster recovery drills were all outside the scope of verification.

Some of the materials treated the prototype's screens as the "confirmed specification". Screens that worked had taken the place of decisions.

The screens ran, but how to handle exceptions, how to divide permissions and how to check the system at acceptance had not been decided. From the buyer's side, the project looks as if it is moving, yet the end never comes into view. We believe the dissatisfaction with cost and communication came from here.

The number of digits is not a measure of the content

Most of a development budget is labor. An estimate is built by multiplying the cost of one person working for one month (the person-month rate) by the people and months required (the effort).

Rates differ less than people assume. In the 2025 survey by the Japan Users Association of Information Systems (JUAS), the person-month rate derived from total cost was 1.27 million yen, and the average for outsourced custom development was 960,000 yen. The average rate for freelance engineering work was 787,000 yen a month in May 2026. Between the high end and the low end, the gap is less than double.

The estimates we see for the same core business system range from a few hundred thousand yen to several hundred million yen. By our calculation, a 300 million yen estimate divided by 1.27 million yen is about 236 person-months, while a 500,000 yen estimate divided by 787,000 yen is about 0.6. The same words describe amounts of work that differ several hundredfold.

The digits change because the amount of work included differs, and so does the number of companies in between. A 2022 report by the Japan Fair Trade Commission describes a case in which, taking the estimate submitted to the prime contractor as 100, the final contract amount fell to 50 as more companies joined the chain. How much of the payment reaches the people doing the work depends heavily on the structure.

A large amount does not mean success either. In the JUAS Corporate IT Trends Survey 2026, among projects of 500 person-months or more, 29.6% left quality complaints, 42.2% went over budget and 47.8% were late. For projects under 10 person-months, each figure was below 10%.

AI has sped up the first 80%

The prototype in this case showed exactly what tends to happen in AI-assisted development. With AI, the shape of screens and features appears quickly. The hard part comes after that. Once a prototype runs, both the buyer and the builder tend to feel that little remains.

A band showing that AI speeds up the first 80% of the work, while vendors should be judged on the last 20%: security, finishing and business rules checked by people

METR, a US research organization, reported that about half of the AI-written fixes that passed automated tests were of a quality the project's maintainers would not merge. In a study published in October 2026 by the US security company Veracode, AI produced vulnerable code in 38% of the coding tasks it was given.

In our experience, AI speeds up the first 80%, and the remaining 20% does not get faster. That 20% holds exception handling, permissions, security and the business rules unique to each company. We use AI in development too, but the question is not whether it was used. It is who checked the output, and how. We covered this in "Building fast is not, in itself, the value".

What we do when we take over partway

When we take over development that has stalled at another company, or whose direction worries the client, we work in the following order. This project was no different.

Fix one baseline. The estimate, the proposal and the feature list became the contractual baseline, and the earlier materials were kept as reference only. Points where the documents disagreed, such as the number of environments and the design of permissions, were logged one by one, agreed with the client and kept on record. The requirements document, which had been a draft, was rewritten on the basis of those agreements.
Write the assumptions into the estimate. The estimate and the proposal stated that this was a rough figure made before the requirements were fixed, that effort could rise by 30% to 60% as open points were settled, and which costs were not included.
Do not let a prototype stand in for the specification. The prototype we rebuilt is not a deliverable but a tool for agreeing on requirements. Decisions are recorded in documents together with their reasons.
Doubt our own work. Midway through development, we entered the data of a fictional second company and ran the system from start to finish. Several features turned out to work only with the first company's data. Of the 29 approved documents in the output, 18 were empty. We fixed them the same day and checked again with the same procedure.

The second-company test shows that even in our own prototype, the last 20% is invisible if you only look at working screens. Six weeks after the rebuild began, 21 of the 40 features were running in the development environment, where the client could check them.

Five places to check in the estimate and the contract before you order

Judge an estimate not by whether it is high or low, but by the work it includes and by who will check that work and how. Using the Model Transaction and Contract for Information Systems from the Information-technology Promotion Agency (IPA) and the Ministry of Economy, Trade and Industry as a guide, check these five places.

The inspection specification. Is it decided before development what will be checked, and how, at acceptance?
The security specification and testing. Does it say which measures are included and who tests them?
The period of liability for nonconformity. Does it state how long defects found after delivery will be fixed?
Copyright. Who owns the rights to the program?
The scope of maintenance. Are support hours, monitoring, updates and incident contact included?

If the estimate says only "one lot", ask for a breakdown by phase. If development is already under way, the shortcut is to ask not for the working screens, but for the record of what was decided to be built and the record of what was checked.

FAQ

Is a high estimate the safe choice?

Not necessarily. A survey shows that the larger the project, the more often it goes over budget or schedule. Judge by who checks inspection and security and how, not by the amount.

Should I avoid a low estimate?

For a low-impact prototype or an internal tool, it is a reasonable choice. If the system handles personal data or the core of your business, first check that the estimate has lines for inspection and security.

Can work started by another company be taken over?

Yes. We read the documents and deliverables, tell you in writing what will be kept and what must be rebuilt, and give you an estimate on that basis.

Shouldn't a company that uses AI be much cheaper?

Writing code has become faster, but the time for organizing requirements, checking and testing has not shrunk in proportion. Estimates differ in how much of that work they include.

Summary

An order one digit larger can still produce deliverables that are not usable. The size of an estimate does not guarantee its content. When choosing a vendor, check that the estimate and the contract say who will verify the last 20%, the part AI does not speed up, and how.

In our estimate consultation, the project manager in charge explains the assumptions behind the estimate and the work it leaves out on a first video call. For development left partway by another company, we look at your documents and deliverables and tell you what can be kept and the likely cost range. The project manager who gives the estimate stays on to run the development. No phone number is required and there is no obligation to order. Book a free estimate consultation

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.