origen.
Origen / Services / Mobile iOS · Android Vol. V · 2026

Apps that survive
their second year.

03.2 / Mobile

We build iOS and Android apps from a single codebase — React Native or Flutter, with Firebase or AWS behind them. Senior engineers write the whole thing, which is why our apps tend to still be shipping in year three rather than being rewritten. Most of our clients are UK companies of seven to thirty people whose product is the business.

All four disciplines →
§ 01

What we build

Three shapes

Cross-platform, in practice, means one team and one codebase — not two half-teams writing the same feature twice.

Build 01

Consumer apps

Apps with real users, real reviews, and a release cadence. Onboarding that does not leak users, push that does not annoy them, and analytics you can act on.

React Native · Flutter
Build 02

Field and ops apps

For teams working away from a desk. Offline-first data capture, sync that survives a bad signal, and interfaces usable in gloves, sunlight, or a hurry.

Offline-first · Sync
Build 03

The mobile half of a platform

When the app is one surface of something bigger. Shared APIs, one source of truth, and the same team on web and mobile so the two never drift apart.

Web + mobile
§ 02

How we work

Senior-led, tested, released

The same senior engineers from first commit to the store listing — no pitch team and then a different build team.

01

One codebase, chosen deliberately

React Native by default: the hiring pool is deeper and most teams already have React people, which matters far more in year two than any benchmark. Flutter when the interface is heavily custom or animation-led. Native modules where a screen genuinely needs them.

React Native · Flutter
02

Tests and releases from week one

Automated builds to TestFlight and internal testing tracks from the start, so you are holding the product on your own phone early and often. Tests on the paths that would embarrass you if they broke: auth, payments, sync.

CI/CD · TestFlight
03

Your accounts, your keys

Apple and Google accounts stay in your name, signing keys and IP are yours, and the handover documentation is written as we go rather than assembled in a panic at the end. Nothing about the arrangement is hostage.

You own it
§ 03

Proof

Three from the shelf
Case 01

CrewPass — flight crew, looked after

Mobile · Portals

An airline-sponsored benefits platform: a crew-facing mobile app plus supplier and admin portals, all on one shared backend.

FlutterFirebaseMulti-portal
Read the case
Case 02

WorX — shipped, relentlessly

Web · Mobile · Retained

A retained engineering partnership across web and mobile for a UK enterprise software company — every release, one team, ongoing since 2025.

React NativeWeb platformRetainer
Read the case
Case 03

MTN — Africa's largest telco

Strategy · Design · Build

A long-running partnership with an enterprise telco — the kind of environment where a release has procurement, compliance, and scale attached to it.

EnterpriseDesignWeb
Read the case
§ 04

Common questions

Straight answers

React Native or Flutter — which should we choose?

Usually React Native, because most teams already have React people and the hiring pool is deeper, which matters more in year two than any benchmark. Flutter wins when the interface is heavily custom or animation-led. We will tell you which one your product wants and why, before anyone writes code.

Will it feel native, or like a website in an app?

Native-feeling is the whole point. Real navigation, platform gestures, sensible keyboard handling, offline behaviour that does not lose work. Cross-platform is a delivery decision, not a quality compromise — and where a screen genuinely needs native code, we write native code.

Who owns the App Store and Play accounts?

You do, in your own developer accounts, from the first submission. We handle the release process, certificates, and review responses, but the accounts, signing keys, and IP are yours. If we part ways, nothing is hostage.

How long does a first release take?

Most first releases land in three to six months depending on scope, with a clickable prototype inside the first few weeks and working builds on your phone from early on. You will not wait until month five to see something real.

Can you take over an app someone else built?

Often, yes — it is a good part of what we do. We start with an audit of what exists and a written memo on whether it is worth keeping. See how a takeover works on our project rescue page.

What happens after launch?

Apps are not finished at launch; OS releases, device changes, and store policy shifts all arrive uninvited. Most clients keep us on a retainer so the engineers who built it are the ones maintaining it.

Got an app to
build?

Tell us what you’re building — it goes straight to Harley and Jonathan, not an SDR, and we reply within 24 hours. Mid-build and in trouble? Start with a rescue instead.