An established company with a working web product and backend infrastructure needed a native mobile app. Rather than rebuild their team from scratch, they brought in an embedded mobile squad. This is how it worked.
The situation
The client had been operating a web product for several years. They had a well-functioning frontend team, a backend team managing a set of internal APIs, and established deployment practices. The product was stable, the team was cohesive, and the business was growing.
The gap was mobile. Their users were increasingly on mobile devices, and a browser-based experience wasn't meeting expectations. The decision was made to build dedicated native apps — but not to disrupt what was already working.
Rather than hire a separate mobile team from scratch or hand the project to an agency and step back, they chose a third path: embed an external mobile team directly into the organisation, working alongside the existing engineers as a single unit.
How the integration worked
Week one: orientation, not delivery
The first week was spent entirely on understanding — not building. The mobile team met with the backend engineers to understand the existing API structure, authentication model, and data contracts. They met with the frontend team to understand the product domain, the edge cases, and the decisions that had already been made.
No code was written. A shared document captured the integration points, the open questions, and the agreed conventions. This was the foundation everything else built on.
Shared infrastructure from day one
The mobile codebase lived in the same version control system as the rest of the product. The same CI platform was used — the mobile pipelines ran alongside the web pipelines, with the same conventions for branch naming, pull request review, and merge gates.
This meant the mobile team was visible to the rest of the organisation from the start. Their work appeared in the same tooling, went through the same review process, and was subject to the same quality standards. There was no "mobile silo."
Working with the existing API
The backend team owned the APIs. The mobile team consumed them. This separation was deliberate and clear from the beginning.
Where the API needed to change — a new endpoint, a modified response shape — the mobile team raised the need, the backend team made the change, and both sides reviewed the contract before any client code was written. This slowed down individual tasks but prevented the kind of late-stage integration failures that cost weeks of rework.
In practice, the backend team needed to make fewer changes than expected. The existing APIs were well-structured. The mobile team adapted to them, and where small wrappers were needed they were written on the mobile side, not by modifying the backend.
How the mobile product was structured
Modular by default
The app was split into independently deployable feature modules from the start. Each module owned its own UI layer, its own business logic, and its own test suite. Modules depended on a shared core layer — networking, authentication, local storage — but not on each other.
This structure had two immediate benefits. First, it made parallel development possible: different engineers could work on different modules without stepping on each other. Second, it made the codebase navigable for engineers joining later — the boundaries were clear and the conventions were consistent.
Remote configuration without code changes
A significant requirement was the ability to change product behaviour without releasing a new app version. Feature flags, content strings, promotional banners, and certain business rules were all driven by a configuration layer fetched from the backend at launch.
This meant the product team could run experiments, roll out features gradually, and respond to business changes without waiting for an app store review cycle. The configuration contract was agreed with the backend team early, versioned, and treated with the same care as any other API.
Testing as a team habit
Testing was not a separate phase. It ran continuously throughout development.
Unit tests ran on every commit. Integration tests — covering the interaction between the mobile app and the real backend staging environment — ran on every pull request. UI tests covering the most critical user journeys ran nightly.
The CI pipeline was configured to block merges if any layer of the test suite failed. This was occasionally frustrating when a flaky test blocked a merge, but the discipline paid off: in eight months of development, no regression that had been covered by a test reached production.
Code coverage was tracked but not treated as a target in itself. The question was always "is this behaviour tested" rather than "what is the percentage." The coverage numbers were a signal, not a goal.
Shared packages across teams
Some of the work done by the mobile team had value beyond the mobile app. A structured logging module, a network abstraction layer, and a set of data transformation utilities were extracted into standalone packages.
These packages were versioned and published to the organisation's internal package registry. The backend team adopted the logging module for their own tooling. The structure meant that improvements benefited multiple consumers simultaneously, and breaking changes were explicit rather than hidden.
What the existing team had to change
Very little, which was by design.
The backend team added a staging environment that the mobile team could use freely without risk to production. They introduced a lightweight API versioning convention to allow gradual migration when endpoints changed. Both of these were improvements they had wanted to make anyway.
The frontend team did almost nothing differently. Occasional conversations about shared product behaviour — how should this state be represented? what happens when the user is offline? — were the extent of the cross-team coordination beyond the shared daily standup.
The integration succeeded largely because the mobile team adapted to the existing organisation rather than asking the organisation to adapt to them.
Outcomes
After four months, the first version of the app shipped to production. After eight months, both platforms were at feature parity with the web product's core flows.
The key results:
- Zero integration failures at launch. Every backend contract had been tested against staging continuously. There were no surprises.
- Full test coverage on critical paths. The CI pipeline ran thousands of automated checks on every change, with the nightly UI suite covering the ten most important user journeys end to end.
- Remote configuration in place from day one. The product team used feature flags to roll out the app to a subset of users before full release, gathering feedback without risk.
- Modular codebase adopted by the internal team. When the engagement ended, the internal team took ownership of a codebase with clear boundaries, documented conventions, and a test suite they understood. Onboarding a new mobile engineer took three days, not three weeks.
- Three shared packages in production. The logging, networking, and data layers extracted during the engagement continued to be used and maintained by the wider engineering organisation.
What made it work
Embedded team engagements fail for predictable reasons: unclear ownership, parallel tooling that never converges, and an external team that works around the existing organisation rather than within it.
This engagement avoided those failure modes by being deliberate about three things from the start.
Clear integration points. Everyone agreed on where the mobile team ended and the backend team began before any code was written. This prevented the endless negotiation that slows down cross-team work.
Shared tooling. One version control system, one CI platform, one review process. No exceptions. The overhead of setup in week one paid for itself many times over.
Adaptation, not disruption. The mobile team adopted the organisation's conventions rather than importing their own. The existing team was never asked to change how they worked to accommodate the newcomers.
The result was a product that felt like it had been built by one team — because, for the purposes of the engagement, it had been.