From Two Legacy Codebases to One Working App — In Three Days

How First Line Software applied its AI-native RACE Programming methodology to unify a healthcare software company’s mobile platform — starting from nothing but source code.

Category: Healthcare · AI & ML · AI-Native Delivery Anthropic Claude
Reading time: 4 min

Client

Zedmed Pty Ltd is an Australian medical practice-management software company serving clinics across the country with scheduling, patient records, and billing tools. Their doctors use a companion mobile app to manage appointments, view patient results, and access patient histories on the go.

Scale: Thousands of doctors across Australian medical clinics. 

Product impacted: Doctor-facing companion mobile app — authentication, dashboard, appointments, patient results, patient records and recalls.

Challenge

Zedmed’s doctor app existed as two separate native codebases — one for iOS (Swift, with legacy Objective-C and storyboards), one for Android (Java, with XML layouts). Different release cycles. Different support teams. Behaviour that had drifted apart over time.

The accumulating cost of maintaining two parallel builds was unsustainable. The brief was deliberately narrow: replace both apps with a single React Native application. Same behaviour, same look and feel, one codebase — a 1:1 migration.

What made the engagement unusual was the starting point. First Line Software received two zip archives — the iOS source code and the Android source code — and nothing else. No API documentation. No test environment. No design files. No mockups. No dedicated technical contact on the client side.

Rather than chase the client for specifications, the team made a deliberate choice: prove that the source code alone, combined with AI-native delivery, was enough to go further and deliver.

Approach

First Line Software applied RACE Programming — its AI-native software delivery framework, developed by the FLS AI Lab. RACE restructures a traditional team into tiers running at different cadences, with AI as a first-class team member rather than a bolt-on tool.

The team on this project:

• Pit Wall (strategic, client-facing): AI Product Lead + ACE Technical Lead — owning architecture, specification, and methodology
• Pit Crew (execution): two software engineers — turning the spec into a working application with AI
• Silicon engineer: Claude Code — performing the bulk of implementation under the engineers’ direction

The team committed to three deliberate bets at the outset:

1. None of them had shipped React Native before. The team was experienced in full-stack development, but React Native, Expo, and native modules were new territory.
2. They committed to spec-driven development with Claude Code on a real production project — a first for all of them.
3. They would validate against their own mock backend, since no backend access or credentials were available.

All three turned out to be the right call.

How it was built — step by step:

Step 1 — Documentation from source code. Rather than writing a line of React Native first, the team applied AI methodology to both legacy codebases and produced structured SDLC documentation: screen maps, API contracts, data models, and user scenarios. In the absence of any client documentation, these AI-generated artifacts became the single source of truth.

Step 2 — Mock backend on synthetic data. With API contracts in hand, the team built a MockServer — an Express-based backend populated with synthetic test data — as the development environment, so the application could be built and validated without access to live systems.

Step 3 — Visual baseline extraction. The corporate colour palette and visual style were extracted from the original apps, giving the new application a starting point that matched the originals’ look and feel.

Step 4 — Spec-driven build. With specification and mock backend in place, Claude Code assembled a functionally working application in approximately half a day. All core screens were operational and behaved correctly. Visual output was still misaligned with the originals at this stage.

Step 5 — Tests from documentation, not from code. An AI agent was given the documentation only — explicitly barred from reading the application code — and used it to author end-to-end test flows. Tests built from an independent starting point give real signal about correctness; having AI test AI-generated code against the same logic closes a loop that undermines confidence.

Step 6 — Screenshot-driven UI matching. A second AI agent ran the documentation-based scenarios against the two original apps and captured screenshots of every screen. It then split each screenshot into individual UI elements, matched them to the corresponding components in the new React Native app, and applied fixes — driving the visual output toward a pixel-accurate match with the originals.

Step 7 — API abstraction layer. A transforms.ts layer was built to abstract the boundary between the mock backend and the real API. When backend credentials were eventually provided, the live system could be swapped in with minimal change — the mock was a designed handover point, not a dead end.

Solution

FLS delivered a single React Native codebase replacing the separate iOS and Android apps, covering all core doctor-facing workflows: Authentication, Dashboard, Appointments, Patient Results, Patient Records & Recalls.

RACE Programming produces SDLC artifacts as a natural by-product of delivery — not as a separate documentation effort. The repository includes:

Specification:

• 30+ executable Given/When/Then scenarios
• C4 architecture documentation (context / containers / components)
• 20+ UI specifications
• 38 sequence diagrams
• Story map, problems catalogue, and glossary

Testing:

• 107 unit and integration tests (Vitest)
• 9 end-to-end user-journey flows (Maestro) covering 130+ automated UI checks

Infrastructure:

• MockServer (Express) with synthetic test data
• transforms.ts API abstraction layer for mock-to-real handover

None of it written for show — it is the working state of the project.

Technology

Core stack:

• React Native + Expo + TypeScript (cross-platform mobile)
• Zustand (state management)
• React Navigation
• axios
• Expo SecureStore / Camera / AuthSession (secure storage, QR scanning, SSO)

Testing:

• Vitest (unit and integration)
• Maestro (end-to-end, 9 flows / 130+ automated checks)

Infrastructure:

• MockServer (Express) + synthetic data
• transforms.ts — mock ↔ real API abstraction layer

AI-assisted delivery:

• Claude Code — used for reverse-engineering legacy codebases, specification generation, React Native application build, documentation, test creation, and screenshot-based UI matching

Results

Three working days from two zip files to a demo-ready application.

Starting from nothing but legacy source code — no documentation, no API specs, no backend access, no designs — First Line Software delivered a documented, tested, cross-platform application ready to present to the client. The first functionally correct prototype was running in approximately half a day.

At the client demonstration:

• All main user scenarios passed end-to-end
• Full test coverage and SDLC documentation were in place
• Visual output matched the original iOS and Android apps

A few minor issues surfaced once the application was connected to live backend data — all anticipated. They were resolved almost immediately. The application is currently in the productionisation phase, with full backend integration as the planned next step.

Before / After Snapshot

AI Enablement

Claude Code was the primary delivery engine throughout — not a productivity add-on.

How AI was used:

• Reverse-engineering both legacy codebases into structured SDLC documentation
• Generating the React Native implementation from that specification
• Authoring unit, integration, and end-to-end tests from documentation (with the AI barred from reading the app code, for independent verification)
• Screenshot-based UI matching for visual parity with the original apps
• Producing architecture documentation as a by-product of the build

Human-in-the-loop throughout: Engineers directed and reviewed all AI output. Architecture decisions, quality standards, and methodology choices remained with the Pit Wall. The silicon engineer executed; the human engineers owned the outcome.

What It Means

This engagement shows what changes when software delivery is restructured around AI rather than adapted to accommodate it. A team of four — none of whom had shipped React Native before — delivered a documented, tested, demo-ready cross-platform application in three working days, starting from two archive files and nothing else.

The gain comes from reorganising roles, artifacts, and delivery cycles around what AI actually does well: building from specifications instead of improvising from intent, generating documentation as part of delivery rather than after it, and using AI agents to do work that would otherwise require additional engineers.

“What we used to treat as the upper limit of a small team is roughly the warm-up now.” — FLS delivery team, Zedmed project

Is RACE Programming Right for You?

RACE Mode works best when:

• You have a legacy system that needs modernising — but documentation, specs, or institutional knowledge are incomplete
• You need to validate a migration or replatform quickly before committing to a full programme
• Speed to working software matters more than process compliance
• You have a narrow, well-defined brief — and you want the team to prove the path before expanding scope

If the source code exists, FLS can build from it.