Summary: Offshore development projects mostly fail because the specification was not clear enough before coding started, not because the engineers are weak or the country is wrong. The gaps only show up when you test the running product. VAON closes them with a Spec Lock Phase (仕様確定フェーズ): written requirements, a fixed-price quote, and the freedom to stop afterwards.
Contents
- Does offshore development fail because of the code or the specification?
- What does a thin specification look like once it reaches an offshore team?
- Does switching countries or adding a bridge engineer fix it?
- What does VAON's Spec Lock Phase (仕様確定フェーズ) include?
- What did VAON do on Seminar Navi for Kochi University of Technology?
- When is a Spec Lock Phase not what you need?
- Five questions to ask any offshore vendor before you sign
- FAQ
1. Does offshore development fail because of the code or the specification?
Offshore development fails because of the specification more often than because of code quality. Code is the translation of decisions. If a decision was never made, even a strong engineer has to guess, and guesses are wrong a fair share of the time.
VAON has no failure-cause statistics to show. The "X% of offshore projects fail because of requirements" figures online usually cannot be traced to a source, so we do not use them.
A better source is the Offshore Development White Paper 2025 (about 1,000 client companies and about 200 vendors surveyed). According to its summary page, the challenges clients feel with offshore vendors remain "communication skills" and "quality control". During vendor selection, the top two are "fit with our own requirements" and "initial communication". The page does not list specifications as a separate item and gives no percentage per cause.
Our view is that poor communication and poor quality are usually symptoms, and a thin specification is the root cause. That judgment comes from our CEO's years in delivery work, not from the survey.
2. What does a thin specification look like once it reaches an offshore team?
A thin specification rarely looks thin. It looks complete until someone asks, "and what happens in this case?"
| Gap in the specification | What the engineer does | When it is discovered |
|---|---|---|
| Business exceptions not written down (partial refunds, cancellation midway) | Picks the most sensible handling by guesswork | At acceptance testing with real data |
| Permissions listed as just "admin and user" | Builds two roles; everything else becomes an exception | When the client tries it with real staff |
| Legacy data to be migrated is not described | Assumes the data is clean | During the first migration trial |
| Error screens, empty states, export file formats | Follows the library default | When end users complain |
| The phrase "same as the old system" | Each side reads it differently | Near the end of the project |
What they share: every gap gets filled immediately with a reasonable guess, so nobody raises an alarm. The cost arrives later, as rework and an argument about whether something was "in the requirements".
Working culture adds to it. In Japan, the person receiving information is expected to put themselves in the writer's position and interpret it fully, so specifications are often written briefly. Teams in other countries tend to build exactly what is written. Neither side is wrong, but the distance between those two readings is the missing specification. Hidden technical limits follow the same pattern; see saying what you will not build before signing.
3. Does switching countries or adding a bridge engineer fix it?
Switching countries or adding a BrSE (Bridge System Engineer) does not fix a specification problem. A specification with missing decisions produces poor results in any country, including with a vendor in your own.
A BrSE solves a different problem: language and working culture. They help the specification get understood correctly. They cannot create a decision nobody has made. And if all the business knowledge sits in one BrSE's head, the project loses it the day that person leaves. How VAON reduces that risk (a BrSE leads the early phase, then design engineers talk to you directly, and knowledge lives in the team and the documents) is covered in offshore development without depending on one bridge engineer.
4. What does VAON's Spec Lock Phase (仕様確定フェーズ) include?
The Spec Lock Phase (仕様確定フェーズ) is a separate, fixed-price phase that produces a specification detailed enough to quote the build. VAON runs it before writing any code.
| Item | Details |
|---|---|
| Duration | 1 to 2 weeks; 2 to 4 weeks for larger projects |
| Price | Fixed, quoted upfront, no additional charges |
| Led by | A BrSE and a Tech Lead |
| Outputs | Requirements document (要件定義書), wireframes for every screen, database design, system architecture, fixed-price quote for the build phase |
| Afterwards | You may stop here; continuing is not required |
There are two entrances, depending on where you start.
Entrance A: you already have a system. VAON reads the code, interviews the people who operate it, and measures the running system. The goal is to learn what it actually does, not what the old documents say.
Entrance B: you have nothing yet. VAON interviews the business side, draws every screen with you, and designs the data. Most missing decisions surface at the screen-drawing step, because you cannot draw a button without knowing what it does.
The right to stop matters. The phase is only worth something if you are free to judge the result without being locked into the next step.
5. What did VAON do on Seminar Navi for Kochi University of Technology?
On Seminar Navi for Kochi University of Technology (高知工科大学), VAON worked with the university from sorting out requirements through to operation. The system is a LINE app (LIFF), a PWA, and an admin screen. It took about five weeks from requirements to operation, officially live from October 1, 2026.
Here are examples of the kind of decision that has to be on paper before coding: students start using it after four steps, about one minute; the system does not collect names; suggestions run on rules, not generative AI. Each sounds small, but changing one after the build means reworking screen flows, data, and reporting.
We have not published usage figures for the system, so none appear here.
6. When is a Spec Lock Phase not what you need?
A Spec Lock Phase is unnecessary when the work is small and clear: changing a screen, adding a report, fixing a bug. A short conversation and a quote are enough.
Three more limits:
- No business owner, no lock. The phase needs someone who understands the real process to join the interviews. If nobody in your company does yet, finding that person comes first.
- A specification from code (Entrance A) has limits. Code shows what a system does, not why. Dead rules, manual steps outside the system, master data, real environment settings, and third-party systems are not in the code. Long-standing bugs can be recorded as if they were rules. So every item is checked with business users.
- Locked does not mean frozen. Requirements will still change. The difference is that each change goes through a written procedure, covered in how to spot a vendor that does not send surprise invoices.
Also, if you need a large team to start coding within days, this phase delays the start, and VAON may not be the right fit.
7. Five questions to ask any offshore vendor before you sign
You can use these even if you never talk to VAON. Vague answers tell you where the risk is.
- Before you quote the build, what document do you produce, and do I keep it if I stop there?
- Who on your team will ask me about business exceptions, and how (interviews, wireframes, real data samples)?
- What document is this quote based on? If it does not exist yet, what assumptions is the price built on?
- When I want to change a requirement midway, what do I receive in writing before the work starts?
- If my point of contact leaves, who continues, and where does the knowledge live?
To see concrete gaps in a project you are about to start, read the article on requirements timelines, costs, and drafting. If the project will use AI to write code, also see 12 questions to check before outsourcing AI-driven development.
8. FAQ
I have no specification at all. Can VAON still help? Yes. That is Entrance B of the Spec Lock Phase. VAON interviews the business side, draws screens with you, and designs the data. You do not need to prepare documents; you need someone who understands the real process to join the sessions.
My system has run for years and has no documentation. What then? That is Entrance A. VAON reads the code, interviews operators, and measures the running system to build a specification of the current state. Each item is checked with business users, because code does not tell you why a rule exists.
Am I obliged to continue with VAON after the Spec Lock Phase? No. You may stop after this phase. You receive the requirements document, wireframes, database design, architecture, and a fixed-price quote for the build, and then decide whether to continue.
Does a Spec Lock Phase make the project more expensive? It is a separate cost with a fixed price quoted upfront. In return, the build quote rests on a concrete document instead of assumptions. The cost of a missing specification usually shows up later as rework, and VAON has no figures to compare the two.
Preparing to hand a project to an offshore team? Bring the questions in section 7 to the first conversation. VAON's first session is 60 minutes, our CEO attends, no documents are needed, and there is no obligation. Book a free 60-minute consultation
Author: Đặng Văn Luân, Founder & CEO, VAON. HEDSPI graduate (Hanoi University of Science and Technology). Worked at FPT Software, spent five years at Digital Plus in Tokyo on a system with 10 million users, then eight years as COO of a 120-person IT outsourcing company, building its ISO 9001 and ISO 27001 management system. 15 years in the industry.
References
- Offshore Development White Paper 2025, Offshore Kaihatsu: https://www.offshore-kaihatsu.com/offshore_hakusho_2025/ (summary page, checked Oct 17, 2026)
