Mobile app development

Mobile app development for marketplaces and on-demand products

The customer books from a phone. The person doing the work is on one too, often with bad signal and one hand free. Those are two different apps and most briefs only budget for the first.

Book a fit check See the platforms

products shipped: 20+products shipped
industry niches: 4industry niches
years building: 4years building

The question is rarely native versus cross-platform.

Teams arrive with the technology decision already framed as the hard one. In practice it is the easy one, and it follows from a couple of facts: how often the app has to work without a connection, whether it needs hardware the web cannot reach, and how fast the product still has to change.

The real cost sits elsewhere. Push notifications that arrive when they matter and not at 2am. State that survives a dead zone and a killed app. App Store review when your release is tied to a marketing date. A worker-facing app that is usable with gloves on and a phone at twenty percent battery.

We build the customer side and the operator side as one system, because they share a backend, a permission model and the same support queue. Shipping them as separate projects is how the two drift apart.

What we build for mobile

Both ends of an on-demand product, not just the shiny one.

Customer apps

Booking, scheduling, address and payment management, order history and live status. Designed to complete a booking in under a minute, because that is the number that decides conversion.

Worker and operator apps

Job queues, accept and decline, navigation handoff, proof of completion with photos, and timekeeping. Built for one-handed use and poor signal.

Offline tolerance

Local state, queued actions and conflict resolution when the connection comes back. A field app that needs full signal is not a field app.

Notifications that earn their place

Push, quiet hours, batching and deep links into the right screen. Plus the fallbacks for when a user has notifications switched off, which many do.

Payments on device

Saved methods, authorisations, tips, refunds and receipts, with the platform payment rules handled rather than discovered during review.

Release and store operations

Store accounts, review cycles, staged rollouts, crash reporting and the ability to ship a fix the same week without waiting on a review queue.

How the build runs

The platform decision first, then one system with two front ends.

01
Platform decision
Web, cross-platform or native, decided from connectivity, hardware needs and release cadence. It takes a conversation, not a workshop.
Week 0
02
Flows before pixels
Both apps mapped against the same backend, including the states that only exist on a phone: interrupted, backgrounded, offline, out of battery.
2-3 weeks
03
Build in one-week sprints
Test builds in your hands from sprint one via TestFlight and internal tracks, so feedback arrives on a device rather than in a document.
8-16 weeks
04
Store launch and beyond
Store submission, staged rollout, crash monitoring, and the first round of changes real usage forces in week two.
Ongoing

Apps we have shipped

Products where the work happens away from a desk.

Pachaca

An on-demand cleaning service needed a complete digital ecosystem across mobile, web, and internal operations.

YachtMate

Private network for yacht club members needed secure, real-time communication

Teya Logistics

Logistics company needed a modern landing page to clearly present their services and attract new clients

All case studies

What we build it with

One backend, two front ends, boring infrastructure.

Apps

React Native
TypeScript
Native modules where needed

Services

Node.js
NestJS
PostgreSQL
MongoDB
Redis

Operations

App Store
Google Play
Push infrastructure
Crash reporting

Questions we get before a mobile build

Cross-platform covers most marketplace and on-demand products, including ours. Go native when you need sustained background location, deep hardware access or platform-specific performance. Stay on web when the product is occasional-use and you want to ship changes daily. We wrote a longer comparison on the blog.

Two to four months for a first version tied to an existing backend, longer when the platform behind it is being built at the same time. Store review adds days, not weeks, once the account setup is done early.

If the people doing the work are not your employees, usually yes – their needs are different enough that one app serves neither well. Sometimes the right answer is a customer app plus a mobile web tool for the workers, which is cheaper and we will say when it fits.

Offline requirements, payments, real-time tracking and the number of distinct user roles. Store presence itself is a small fixed cost; the variable is how much of the product has to keep working when the network does not.

Yes, after an audit. We will tell you honestly whether the codebase is worth continuing or whether the remaining work is cheaper on a fresh foundation. We have recommended both.

You do. Apps are published under your developer accounts, with your certificates, so you are never locked to us for a release.

Tell us where the work happens. Thirty minutes, no pitch. We will tell you which parts genuinely need an app and which are fine on the web.

Book a call

Worth reading before you brief anyone

On platform choice, booking flows and what a build actually costs.