What goes wrong when choosing a development partner?
If you are reading this page, you have likely received a system that matched the specification and produced no result. This is common, and the cause is usually not engineering capability.
Three failure patterns repeat in outsourced projects:
- Correct logic, worse workflow. The system calculates accurately, but a task that used to take three steps now takes eight. Staff return to spreadsheets.
- Correct spec, real data breaks it. The spec was written against clean sample data. Production data has blank fields, duplicate codes and special characters — the flow fails in the first week.
- Correct feature, wrong purpose. The request was an "export to Excel" button. The real goal was the Monday morning report to head office. The button works as specified, and the report still takes half a day.
All three pass acceptance testing. All three are failed projects. We covered the four metrics that measure software quality after handover in a separate article.
When deciding how to build, you are weighing these options:
| Option | Strength | Limitation |
|---|---|---|
| In-house hiring in Japan | High control, strong domain knowledge | High headcount cost, long hiring cycle |
| Domestic Japanese outsourcing | No communication barrier | Highest cost of all options |
| Freelancers | Low cost, fast start | Inconsistent quality, risk of mid-project drop-off |
| Offshore without a coordinator | Low cost | Requirement drift, heavy rework |
| Managed offshore with a resident BrSE | Balances cost and quality, single point of accountability | Requires clear acceptance criteria and reporting cadence from day one |
VAON operates the last model. You can review how VAON's team works with Japanese clients before reading on.
What is included in the full-cycle service?
VAON takes responsibility from clarifying business goals through to improving the system after it runs in production. You work with a single point of accountability instead of coordinating several vendors.
The scope maps directly to the limitations in the table above:
| Area | What it covers |
|---|---|
| Consulting and goal definition | Identify the metric to improve before locking the feature list |
| UI/UX design | Designed against real operational flows, not against a paper spec |
| Engineering | Web, mobile, internal systems, AI integration |
| Dual-layer QA | Technical testing (unit/integration) plus usability testing |
| BrSE (Bridge System Engineer) | Translates business context between the Japanese client and the delivery team |
| Operations and post-release improvement | Track usage metrics, propose and execute adjustments |
One point to state plainly: VAON commits to measuring and reporting usage outcomes, not to a specific ROI figure. ROI depends on marketing, operational and market variables outside a technical partner's control. A vendor that commits to ROI contractually is selling something it does not control.
How does VAON work, and how long does each step take?
The process has five steps. The durations below are typical for a mid-sized system; more complex projects take longer and the estimate is stated in the proposal.
- Current-state Audit — 3–5 working days. Review the existing system, available data, and the acceptance criteria in use. The output is a short report, free of charge and with no contractual obligation.
- Goal definition and estimation — 1–2 weeks. Identify the metric to improve, the minimum scope that moves it, and the required team and timeline.
- Design and acceptance criteria — 2–4 weeks. UI/UX designed against real operational flows. Acceptance criteria are written jointly and include the metrics measured after release.
- Development in 2-week sprints. Each sprint delivers a running build for you to review. Weekly progress reporting in Japanese or English through the BrSE.
- Go-live and improvement — the first improvement cycle is inside the contract. The hour limit is stated upfront so neither side has to argue scope when an issue arises.
Working languages: Japanese (via BrSE) or English. Reporting cadence: weekly, plus a review session at the end of each sprint.
Handling requirement changes: a change raised during a running sprint goes into the next sprint backlog with an impact estimate before you decide. VAON does not refuse changes on the grounds that they are "not in the spec", and equally does not accept changes without re-estimating.
Three layers of quality control
| Layer | Who performs it | What it catches |
|---|---|---|
| 1. Self-check against acceptance criteria | The assigned engineer | Deviation from agreed criteria |
| 2. Peer review | An engineer not involved in that module | Logic errors, duplication, missing exception handling |
| 3. Business-perspective acceptance | BrSE | Code is correct, the business outcome is wrong |
The third layer is the decisive one, and the one most outsourcing models skip — it requires someone who understands both the business and the technology.
What has VAON delivered?
OneBot — customer service automation system. VAON built OneBot on exactly the model described above: goals clarified first, design based on how the support team actually handles requests, and usage data tracked after the system went live.
At a company providing store-operations support services, roughly 60% of routine inquiries moved to automated responses. The remainder still goes to staff, and the support team now concentrates on the requests that genuinely need a person.
The team
VAON runs a 15-person team covering every role needed to own the full lifecycle, with nothing subcontracted:
| Role | Notes |
|---|---|
| BrSE (Bridge System Engineer) / PM | 2 BrSE, both with 10+ years working with Japanese clients |
| Technical Leader | Owns architecture and the peer-review layer |
| Fullstack Developer | Web and internal systems |
| Mobile Developer | iOS / Android applications |
| Designer | UI/UX designed against real operational flows |
| QA | Technical testing and usability testing |
Fifteen people is a deliberate number. The team is small enough that both BrSE hold the context of every active project, and large enough that no role in the delivery lifecycle has to be subcontracted.
How is cost calculated?
VAON does not work from a fixed price list. Cost is built backwards from your budget and your goal: identify the metric to improve first, then identify the smallest scope that moves that metric within the budget available.
This means budget determines scope, not the quality process. A small project still passes all three control layers and still gets a post-release improvement cycle; what changes is how many business flows fall inside scope.
Three factors drive cost:
| Factor | How it affects cost |
|---|---|
| Business scope | Number of operational flows to digitise — the largest single factor |
| Team composition | Projects needing mobile, AI or legacy integration require additional roles |
| Commitment length | Longer commitments carry a lower monthly rate than short engagements |
Two charging models:
| Model | Fits | How it is calculated |
|---|---|---|
| Dedicated Team | Companies with a long-term product roadmap needing a stable team | Per engineer per month, committed quarterly or annually |
| Fixed-scope project | Systems with defined scope delivered against milestones | One quotation covering the full lifecycle, including the first improvement cycle |
The current-state Audit is free and returns an estimate based on your specific situation rather than a generic figure.
When is VAON not the right choice?
Three cases where another option fits better:
- You need to start within a week. Goal definition and acceptance criteria take a minimum of 3–6 weeks before the first line of code. If you need engineers coding immediately, freelancers or staff augmentation suit you better.
- You only need extra developers on an existing team. If you already have a PM and your own process and are simply short on engineering hands, plain staff augmentation costs less. The BrSE role and the business-acceptance layer would duplicate what your team already does.
- You cannot grant log access or access to end users. Without usage data, every post-release metric is guesswork, and the distinguishing part of this model cannot function.
Stating the limits is considerably cheaper than discovering the mismatch in month three.
Next step
If you are running a system whose results are unclear, or selecting a partner for a project about to start, the sensible step is assessing the current state before committing budget.
The VAON Audit runs 3–5 working days and returns a short report: where the acceptance criteria in use have gaps, which metrics can be measured today with existing data, and where logging must be added before the next phase. No contractual obligation.
Book a free Audit · sales@ai.vaon.com.vn · vaon.com.vn/en
Frequently asked questions
Is our budget large enough? VAON works across a wide range of budgets because scope is built backwards from the budget, not the other way around. We start by asking which metric you need to move, then define the smallest scope that moves it within the budget you have. The quality control process stays the same at every project size.
How is the language barrier handled? A resident BrSE (Bridge System Engineer) works with you directly in Japanese and converts that into technical requirements for the delivery team. Weekly progress reports and sprint review minutes are in Japanese. You do not need to communicate with engineers in English.
How is code quality assured? Three layers: self-check against acceptance criteria, peer review between engineers, and business-perspective acceptance performed by the BrSE. VAON also tracks the post-release defect escape rate and presents that figure at regular reviews, including when the number is poor.
What happens if the project misses the acceptance criteria? Deviation from signed acceptance criteria falls under warranty, at VAON's cost. Where the spec was correct but real usage shows the design needs changing, that falls under improvement — and the first improvement cycle is already in the contract with a stated hour limit. The two scopes are separated at signing, not negotiated when an issue appears. See also how warranty differs from post-release improvement.
Who owns the intellectual property? All source code and intellectual property transfer to the client on completion of contracted payment. This clause is written into the contract and does not depend on whether you continue with VAON for operations afterwards.
Is there an obligation to engage after the Audit? No. The Audit returns an independent current-state report you can use with any vendor, including your in-house team. This is how VAON assesses fit before either side spends time on contract negotiation.
How long does it take to start? Audit 3–5 working days, goal definition and estimation 1–2 weeks, design and acceptance criteria 2–4 weeks. The first development sprint typically starts 4–7 weeks after the Audit, depending on system complexity.
