The app shipped.
Then nobody was
left to maintain it.
At one startup I worked with, the app went live on schedule. React Native, reasonably clean code, both stores approved. Six months later, the vendor had moved on, a minor OS update had broken the notification layer, and there was no one left who knew the codebase well enough to fix it without a full rewrite.
That's not unusual. Most mobile development contracts are written around delivery — App Store approval, that's the finish line. What happens after go-live is rarely in the scope, and even more rarely in the team's actual plan.
The lab model was built for that gap. iOS, Android, or React Native — a dedicated team that's still in the room six months after launch. Not as a support contract. As the team that built it.
vs. a Tokyo engagement
still running post-launch
to App Store submission
Three situations we see
most often before teams reach out
The platform and the industry are always different. The underlying structure of the problem usually isn't.
The product is clear in your head — or in a product spec document. You know whether it's iOS-first or cross-platform. You know what the core flow looks like. What's missing is a team that can actually build it, without the overhead of hiring in-house engineers who won't be busy enough to justify full-time headcount once the build phase is done.
Hiring is slow and expensive for a two-year project. A freelancer team is fast to start but hard to coordinate. What most founders at this stage actually need is a small, dedicated team that can move from spec to App Store without needing to be managed at the task level.
Version 1 is live. The vendor who built it has moved on, and now you need to add features — or fix something the users started reporting. The people who know the codebase are gone. The new team is rereading someone else's code, and every estimate they give you feels like it's accounting for the risk of what they haven't found yet.
I've seen this pattern more often than the original build failing. v1 succeeded precisely because it was scoped tightly. v2 reveals that nothing was built for continuity — no documentation, no architecture notes, no test coverage that tells the next team what behavior to preserve.
App Store and Google Play have it. Users are active. OS updates happen twice a year and break something both times. New features need to ship, but the vendor relationship was a project contract — it ended at launch. You're either paying for one-off fixes with no context, or you're looking for a team that will actually stay.
The realistic options are re-hiring in-house, finding a new vendor and re-explaining the codebase from scratch, or building a relationship with a team that was designed to stay. Most maintenance contracts are written to avoid accountability. That's the part we do differently.
What separates a dedicated lab team
from a project-based mobile vendor
Most mobile development contracts are built around a delivery milestone — App Store approval. The lab model is built around what comes after.
- Team assembled for the project — disperses after App Store approval
- Knowledge in developers' heads, not in documented architecture
- Scope changes trigger renegotiation and delays
- Post-launch support is a separate contract, different team
- No continuity when OS updates break existing behavior
- Same team from first sprint through ongoing maintenance
- Architecture documented sprint by sprint — survives team changes
- Scope changes handled in sprint reviews, not contract amendments
- Available from month one of go-live — no handover gap
- OS update response by the team that wrote the original code
Three things that are different
about how this team builds apps
Platform decision before team assembly. Every mobile project starts with the same question: React Native or native? Most vendors answer it in the first sales call, based on their team's existing skills. We answer it in the Discovery phase, based on your product's actual requirements — expected device range, offline behavior, animation complexity, existing codebase dependencies. At one engagement, the client came in certain they needed native iOS. By the end of Discovery, React Native was the right answer — and we had the data to show why.
We found this in week one of Discovery, before the architecture decision was locked.
React Native saved them four months of parallel build time.
App Store submission is in the contract. Not "we'll help with it." In scope, on the sprint plan, with the same QA gate as every other feature. App Store rejection is one of the most common places a mobile project stalls — provisioning profiles, privacy descriptions, in-app purchase configuration, screenshot specs. We've submitted to both stores across multiple engagements. The process is documented. The first submission isn't an experiment.
The team that builds it stays. We've run two mobile projects now in their second year of maintenance — same team, same codebase, same IT Director who remembers why the push notification architecture was built the way it was. When a major iOS release breaks something, the team already knows where to look. That's not a soft promise about culture — it's a structural outcome of the lab model.
Vietnam offshore mobile development — but the "offshore" part is structural, not just a cost story. The lab is built so the team that ships the app is still in the room six months later when an OS update breaks something. Tokyo equivalent costs roughly 2.5–3× for the same seniority — but that's the side effect, not the headline.
Most mobile vendors will
get you through App Store.
Almost none of them are
still there when iOS 20
breaks something.
What comes up in almost
every conversation before committing
Regardless of whether you've built a mobile app before or this is the first one.
Will the app actually work the way I imagined it?
What if the lead developer leaves mid-build?
What if the vendor disappears after App Store approval?
There's a practical layer too. Architecture decisions are documented sprint-by-sprint as part of how the work runs — not as a handoff document produced once, at the end, when everyone's already moved on. When an OS update breaks the notification layer six months after launch, the engineers who wrote that code are still on the engagement and already know where to look. The field note above — 26 months, three of three original engineers still on the team — is what that structure looks like in practice.
Choose how involved
you want to be
Both models use the same team. The difference is where the coordination sits.
Your product lead communicates directly with our IT Director. No coordinator in between. Our IT Director functions as your mobile tech lead — taking product direction, breaking it down for the engineering team, and surfacing blockers before they become delays.
You see the sprint board. You're in the biweekly review calls where you tap through working software. You're as close to the team as you want to be.
A Japanese PM joins from product definition through App Store submission, working as the bridge between your business context (in Japanese) and the Vietnam engineering team (in English). Handles UX wireframing, spec design, sprint planning, stakeholder alignment, and store submission coordination — without a translator in the middle, because the PM is operating fluently in both directions.
The PM starts by mapping the actual user flow — what the user does step by step — before any screen is designed. Most mobile failures start when a team skips that part.
From first call to App Store
and beyond
The lab model starts before the first line of code. It doesn't end at store approval.
Three mobile engagements,
what actually happened
Not descriptions of what we can do — what happened at specific companies.
The React Native decision came out of Discovery, not assumption. We had both store submissions approved within the same week, which is less common than it sounds when the submission process isn't planned in advance.
The same team that built v1 is still running the maintenance engagement. Every major iOS and Android version transition has been handled by the engineers who wrote the original code. No regressions from any OS update in 26 months.
The engagement started as a PoC: four weeks to a working prototype that validated the core assumption before the full build was committed. The prototype spec became the actual v1 plan.
Flutter was the right call out of Discovery — one codebase, one design system, one team. We've shipped multiple Flutter apps in similar shape since: B2B business matching apps, in-store promotion apps, and others where "one source, every platform" fits the product reality.
Honest note
This is not the right fit if:
- ×You need a working prototype in one week for under $1,000 — that's a different kind of work
- ×The spec is fully locked and you want the lowest bid to execute it exactly — no questions, no Discovery
- ×App Store approval is the finish line — what happens after launch is someone else's problem
This is the right fit if:
You want a team that's still there after launch
- ✓The app is a core product — not a one-time project — and needs to evolve over months or years
- ✓You've been through an offshore build before and something about the continuity didn't work
- ✓You want a vendor who can still answer the phone two years after go-live — not just at handoff
Not sure if mobile is the right layer?
Measure first
Measure your readiness and your cost — right here
Reaching out cold can feel like a big step. So before that, two free tools to see — right here — whether offshore development fits your company, and how your cost would change. Bring the result to a 30-minute session, and the conversation moves a lot faster.
Is now the right time for you?
Answer eight questions and we score your readiness, then send back three specific recommendations from your answers. Not “you should do this” — “here’s what to do, in your situation.”
Check your readiness → Cost calculator / instantHow much would your cost change?
Enter your team size and budget, and see how the next 12 months change — right here, with the reasoning behind the numbers laid out.
Calculate your cost →
In 30 minutes, let's find out
if this is the right structure for your app.
You have an app idea, or a live app that needs a team. Either way, the first question isn't about React Native versus Swift. It's about whether the structure we use — dedicated team, sprint-based accountability, ongoing past go-live — fits the reality of your project.
If anything on this page felt like it was describing your situation, that's enough to start. Use the 30 minutes to say it out loud. If this isn't the right fit, I'll tell you directly.
I've been running development teams in Vietnam for over a decade. The failure pattern is consistent: the app ships, the vendor moves on, something breaks, and there's no one left who understands the codebase. I've seen it enough times that the lab model wasn't a product decision — it was the obvious structural response.
Common questions about mobile app development
with a Vietnam team
Each has a different center of gravity in 2026. Flutter holds roughly 46% of the cross-platform market and is what Google Pay, BMW, and Toyota chose for pixel-perfect UI and consistent performance across devices. We've shipped multiple Flutter apps ourselves — career services (AI essay review for university students), B2B business matching, in-store promotion — the cases where "one source, every platform" matches the product reality. React Native holds 35–38% and is what Meta's entire app family, Discord, Pinterest, and Microsoft Teams run on — the same engineers can share code with React web apps and tap into a much larger JavaScript talent pool. iOS Swift and Android Kotlin remain right for apps with deep OS integration, heavy native APIs, or complex animation work.
The platform decision comes out of Discovery — based on your product's actual requirements, not which framework the team happens to prefer.
Here is the honest version of what submission looks like on complex apps: we treat Apple rejection as a near-certain event, not a worst case. If your app touches payment flows, UGC, or B2B matching, you are navigating Guidelines 3.1.1 (In-App Purchase), 1.1 (Objectionable Content), 1.2 (UGC moderation requirements), and 3.2.2 (Unacceptable Business Practices) simultaneously. Each one has a live rejection risk on first pass.
The approach that reduces the cycle time: prepare the English appeal before you submit, not after the rejection arrives. We draft rebuttal templates for each applicable guideline in advance — citing Apple's own language, building the argument for why the specific feature does not fall under the cited rule. When rejection lands, the response time drops to hours, not the two or three weeks that happen when the team is reading the guideline for the first time after the fact.
On In-App Purchase rejections specifically: if Apple classifies an ad listing or profile visibility feature as premium content access triggering Guideline 3.1.1, the fix is structural, not a copy change. We've removed all "Buy," "Purchase," and charge-related language from UI and inserted a business information entry step before any external payment redirect — the structural argument that placement fees and feature unlocking are legally and functionally distinct.
The first submission isn't a guess. The common rejection scenarios are mapped, the appeal templates exist before the build is finished, and the team has been through this on Japan's largest B2B business-owner matching app — four guidelines in parallel, resolved.