Two native apps to one React Native codebase

Two codebases, one product

The client maintained two separate native mobile apps: one for iOS, one for Android. Two codebases, two support teams, two release cycles, the same product. The brief was simple to state and hard to do well: replace both with a single React Native application, a one-to-one migration that kept the same behaviour, the same user experience, and the same look, in one codebase. The benefits to the client were obvious; the question was whether it could be done fast, and from a standing start.

Two zip files, and nothing else

Most engagements open with a discovery phase: a kickoff call, a shared Figma file, requirements, a test environment, credentials. This one did not. The team received two zip files: the source code for the iOS app and the Android app. No requirements, no specs, no designs, no test environment, no credentials, no API access.

That was deliberate. The team wanted to prove, to the client and to themselves, that the two archives plus the RACE Programming approach were enough to deliver value without chasing the client for specs or guidance. It meant making three bets at once:

• None of the team had built with React Native, Expo, or native iOS/Android modules before.
• None had run a spec-driven, documentation-first project on real work before.
• With no backend, everything would be validated against the team's best reconstruction of the old apps, not the real thing.

A small team, aligned to the framework

Three people, split across the two RACE Programming tiers and working with the Silicon Software Engineer (the AI agent, here Claude Code):

• Pit Wall: an AI Product role (translating intent into documentation and Executable User Stories) working with an Forward Deployed Engineer who guided the architecture and the methodology.
• Pit Crew: two Pit Crew Software Engineers who ran the inner cycle: generating, validating, and correcting AI-written code against the documentation.

Two techniques carried the work. First, documentation as the contract: an AI agent with no access to the project code used the documentation alone to write test cases and automated UI tests (in Maestro), breaking the loop where an AI is asked to test its own code. Second, reconstruction from screenshots: the team captured every screen of the old apps, and the AI agent decomposed those screenshots into UI elements, matched them to elements in the new codebase, and corrected the visual style until the result was near-pixel-perfect.

Three days from source archives to a working demo

In three working days, starting from only the old codebases, the team had a working, near-pixel-perfect React Native app, with documentation and automated test coverage, good enough to put in front of the client. It ran against a mocked backend and was not yet production-ready; the point was to show, fast, that the approach worked.

The client was visibly surprised by the pace, and granted backend and test-environment access. Connecting to the real backend surfaced a few small issues (some unexpected API behaviour, an SSO login flow that needed work) exactly the kind of thing a mocked reconstruction cannot catch. From there the team moved to one-day Stints: feedback became updated documentation and Executable User Stories, the AI agent implemented them, the tests ran, and a new build was released and demonstrated within a single day, not a two-week sprint.

How much faster, overall? The team is candid that it cannot be precisely measured; there was no parallel conventional build to compare against. But asked for a gut-feel estimate, they reckoned a migration like this would have taken about a month the conventional way (roughly twenty working days) against the three working days it actually took. On a like-for-like working-day basis, that is about seven times faster. A subjective estimate, not a benchmark; the order of magnitude is the point.

A race team in practice

The team is clear that they were not a textbook RACE Programming team; the project predated the framework's formalisation and skipped parts of it. But the core held up under real constraints: a compact team, a Silicon Software Engineer in the loop, documentation-as-code, spec-driven development, and one-day Stints were enough to turn two source archives into a working, near-pixel-perfect application, and to establish, in days, that First Line Software could move at a pace the client had not expected. What used to be the upper limit for a conventional team became the warm-up.