How we build — web and mobile in one repository
One repository, three releases
A web console, an iOS app, an Android app and a database underneath. Most teams run that as four codebases and four release days. This is the setup we build instead — one repository, two branches, and a push that releases all of it at once. It is running in production right now, and it is the same shape we would set up for you.
What this is
A way of building, not a product
Fits
Anything with a web app and a phone app
Stack
Next.js 16, Expo, Supabase, Turborepo monorepo
Status
In production, shipped to both stores
A push to the main branch migrates the database, deploys the console and publishes both phone apps. There is no release day.
- 3systems released by a single pushthe database migrates, the console deploys, both apps publish
- 2complete environments, preview and productionseparate databases, separate hosts, separate apps on the phone
- 1typecheck across every workspace at oncea broken shared contract fails there, before anything builds
- 5specialist subagents living in the repomigrations, domain engine, conformance, scenarios, verification
The problem: four codebases drift apart
A product with a web console and two phone apps is usually built as separate repositories — a front end, an iOS app, an Android app, a backend — each with its own release, its own idea of what the API returns, and its own copy of the business rules.
The copies are the expensive part. The moment the same rule is written twice, the two versions begin to disagree, and the disagreement surfaces as a bug that only appears on one platform. Every release day is then spent proving that four things still match.
The shape: one repository, four workspaces
A Turborepo monorepo with the web console, the phone app, the domain engine and the shared API contract side by side. The engine is a pure TypeScript package with no build step: the console and the server compile the same source files, so a result computed in the browser and the same result computed on the server are provably the same code, rather than two implementations that agree for now.
One typecheck runs across every workspace at once. A change to the shared contract that breaks the app fails there — before anything is built, deployed or installed on a phone.
- Web console — Next.js 16 and React 19, App Router, with its own API routes
- Phone app — Expo, shipped to the App Store and Google Play from the same repo
- Domain engine — pure TypeScript, deterministic, tested against a catalogue of scenarios
- Shared contract package — the response shapes and enums both sides agree on
Environment is a git branch, and nothing else
Two environments, each complete down to its own app icon on the phone. The preview branch has a preview database, a preview web host and a separate Preview app. The main branch has the production database, the live site and the store app. There is no environment switch, no config flag and no staging server that drifts.
That is what makes the release boring, which is the point: a push to main migrates the database, deploys the console and publishes both apps. A reviewer signs off on the preview app on their own phone, against preview data, and the same commit then goes live everywhere.
Where the speed actually comes from
This is not a toy configuration. In the production codebase we counted it on, the setup carries 879 commits made in nine weeks across 1,020 TypeScript files, with 111 database migrations and 37 pgTAP test files behind them.
That pace is not typing faster. It comes from the repetitive, rule-bound work being handed to specialists: five subagents live in the repository, each with one job and the standard for it written down — one authors migrations and their tests, one implements the domain engine, one audits that engine against its spec, one writes test scenarios, one verifies a finished piece of work against the code rather than against a status line.
The rule that keeps it honest is written into the repo guide: a tracker records what was built, so a claim is checked against the code and the tests, never against a line in a document that says it was done.
How a change reaches a phone
What this case does not claim
This is a description of a setup, not of somebody's product. The figures are structural — what the repository holds and what a push does — plus volume counted in a production codebase running exactly this shape. None of them is a business result: what a product built this way goes on to do for its users belongs to whoever owns it, not to us, so you will not find an invented percentage here.
We can set this up for your product
Starting from scratch, or holding a web app and a phone app that have already drifted apart — this is the shape we put them in. Thirty minutes is enough to say whether yours fits it.