Services / Mobile / Customer apps

The app your best customers already want on their home screen

Your repeat buyers are the ones worth building for. An app already knows who they are, takes an order or a booking in a couple of taps, keeps working when the signal drops, and can reach them with a notification instead of hoping they open an email.

Start the conversation →See the technology

Why it matters

The cost is the wait

Every visit to your website starts from nothing. The customer has to find you again, sign in again, and re-enter details they gave you last month. For a first-time buyer that is simply how the web works. For someone who comes back every week it is friction you are charging them for the privilege of tolerating, and it is a large part of why repeat business drifts to whichever marketplace already remembers their card.

An app earns its place by doing the things a browser tab cannot. It knows who is holding the phone before anyone types anything. It keeps the catalogue and the last order on the device, so it still opens on a train with no reception. It can put one line on a lock screen at the moment it is useful: the table is ready, the order has shipped, the class you wanted has a space. And it can take payment with a fingerprint. Strip those out and what you have is a slower website with an icon, which is both a waste of money and, in Apple's case, a likely rejection.

We build the whole thing: the scoping that decides what belongs in version one, the design and prototype, the app itself for iPhone and Android from a single codebase, the servers and payments behind it, the notification strategy, a private beta with your real customers, and submission to both stores. The developer accounts are opened in your name, the source code is yours, and the analytics tell you honestly which features earned their keep.

What you actually get

Built to be trusted

A customer app lives or dies on a handful of moments: the first open, the sign-in, the checkout, and the notification that either brings someone back or gets the app deleted. That is where the work goes.

Sign-in that doesn't lose the sale

People can browse, search and fill a basket before anyone asks them for anything. When the moment finally comes it is Sign in with Apple, Google, a passkey or a one-tap code, then Face ID or a fingerprint every time after, with credentials held in the phone's secure hardware rather than ordinary storage.

Paying in two taps

Apple Pay and Google Pay for physical goods and services, the stores' own purchase flow for digital ones, and saved cards where that suits you better. We map your products to the right side of that rule before we build, because getting the boundary wrong is one of the more expensive ways to be rejected.

Availability that is actually true

Slots, stock and delivery windows read from the same system your staff use, with the locking that stops two people claiming the last appointment or the last unit. An app that shows availability it cannot honour costs you more goodwill than having no app at all.

Notifications people keep switched on

Per-topic controls instead of all-or-nothing, timed around the customer's day rather than your marketing calendar, and opening straight to the screen they refer to. We watch opt-outs and uninstalls alongside opens, because a campaign that wins taps and loses subscribers is a loss.

Still works on the underground

The catalogue, recent orders, the membership card and the booking confirmation stay on the device. Actions taken with no signal queue and sync when it returns, and we agree with you in advance what should happen when a queued action no longer makes sense by the time it lands.

Reasons to come back

Loyalty balances, tiers, saved favourites, reorder in one tap, and passes that sit in Apple Wallet or Google Wallet so a regular can use their card without even opening the app.

Where it earns its keep

Same pattern, different desks

The shape repeats across sectors, a business with genuine repeat custom and a checkout worth shortening. What changes is which of your systems the app has to tell the truth about.

01 · Restaurants & takeaway

Owning the repeat order instead of renting it

The problem: Your regulars order through a delivery marketplace that owns the relationship, takes a commission on every order, and shows them three competitors on the way to your menu. You never learn who they are, so you cannot bring them back yourself.
What we build: Your own ordering app with saved favourites, one-tap reorder, collection as well as delivery, and table booking, wired into the same till and kitchen system your staff already use, so the menu, the prices and the sold-out items are never wrong.
What changes: The customers who order most often have a direct route to you, the contact details and ordering history are yours, and every order placed in your app keeps the margin the marketplace was taking.

02 · Retail & e-commerce

The shelf your best customers carry with them

The problem: Mobile traffic is the majority of your visits and the minority of your revenue. Baskets are abandoned at the address form, back-in-stock emails go unread, and you have no way to reach someone at the moment the thing they wanted arrives.
What we build: An app on top of your existing store (the same catalogue, stock and orders) with wallet-based payment, saved addresses, in-store barcode scanning, and restock and price-drop alerts that go to the lock screen instead of a promotions tab.
What changes: A shorter checkout for the people who buy most often, a direct line to them that does not depend on an email being opened, and a clear read on which alerts drive orders and which drive uninstalls.

03 · Gyms, salons & clinics

Bookings without the phone tag

The problem: Appointments are booked by phone during opening hours, changes are made by phone, cancellations often are not made at all, and the empty slot is discovered too late to sell. Staff spend the day interrupted by the handset.
What we build: An app booking against your real diary, with reminders and one-tap rescheduling, waiting lists that fill a cancellation automatically, class timetables, membership passes in the phone's wallet, and payment or deposits taken up front.
What changes: Fewer no-shows, cancellations that turn back into revenue instead of dead time, and a front desk that can concentrate on the person standing in front of them.

The technology

The tools behind it, named

One codebase, both platforms, and native code only where a feature genuinely demands it. Everything below is chosen per project against your feature list and your monthly running budget, and explained, rather than defaulted to.

6 layers · 35 technologies

The app itself

One team, one codebase, two genuinely native apps. Native modules get written for the specific features that need them, not for the whole product.

React Native
Expo
TypeScript
Swift
Kotlin
Flutter

Taking the money

Physical goods and services go through card and wallet payments; digital goods have to go through the stores. We map your products to the right rules before a line is written.

Stripe
Apple Pay
Google Pay
RevenueCat
Adyen
PayPal

The engine behind it

Servers shaped around mobile reality. Small responses built per screen, so one view does not need six round trips over a weak connection.

Node.js
PostgreSQL
Redis
GraphQL
Firebase
Supabase

Bringing people back

Notification delivery, the certificates behind it, and the passes that let a customer use their card without opening anything.

Firebase Cloud Messaging
Expo Notifications
Apple Push Notification service
OneSignal
Apple Wallet & Google Wallet passes

Plugging into the shop you already run

The app should read your existing catalogue, stock and orders rather than becoming a second place your team has to keep updated.

Shopify
WooCommerce
WordPress
Contentful
Sanity
Algolia

Tracking, maps and measurement

Where the order is, where the branch is, and which parts of the app people actually use, measured against goals we agree with you, with privacy handled properly.

Google Maps
Mapbox
Sentry
PostHog
Mixpanel
Google Analytics

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

A first customer app is usually a twelve to sixteen week job from workshop to store listing. The honest variable is not the app. It is how many of your existing systems it has to tell the truth about.

We decide what version one is not

The first workshop produces two lists, and the second one matters more. Everything cut is written down with the reason, so nobody has to relitigate it in month three, and so the features that survive get the attention they deserve.

A clickable prototype before any code

You and a handful of real customers walk through the actual screens on an actual phone. Changing a flow at this stage costs an afternoon. Changing it after the backend is built costs a fortnight, which is why we spend the afternoon.

We connect your real systems first

Till, stock, diary, payments, CRM. This is where projects overrun, so we do it early rather than saving it for the end, and where a system cannot give us what the app needs, you find out in week three instead of week twelve.

Build in slices you can hold

Every two weeks a working build lands on your phone with something real in it. You are never waiting on a demo date to find out whether the thing you described is the thing being built.

A private beta with real customers

Your team and a pilot group get each version through TestFlight and Google Play's closed testing tracks, with structured feedback collected. Crash rates and startup times are tracked per build, and we agree a quality bar the app must clear before it goes anywhere near the public.

Store submission, then a rhythm

We handle the declarations, listings and screenshots on both stores and manage the review. After launch it becomes a routine: a regular update cadence, crash and funnel review, and a decision each month about what the numbers say to build next.

Before you commit

The questions worth asking

Do we actually need an app, or would a better website do?

Very often a better website is the right answer, and we will say so. An app pays for itself when there is genuine repeat use, when notifications change behaviour, when the app must work without a connection, or when you need the camera, location or wallet. If your customers buy from you twice a year, an app will sit unopened on a home screen and you will have paid for two of everything. We would rather lose that piece of work than build it.

How long does app-store review take?

Most submissions come back within a day or two on both stores, but there is no guarantee and no service level you can hold them to. The first submission is always the slowest, because account verification, privacy declarations and age ratings are being checked for the first time. Rejections happen (sometimes for a genuine mistake, sometimes for a reviewer's reading of a rule) and each one restarts the clock. We plan for at least one round of that rather than promising a date we do not control.

One app for both iPhone and Android: is that a compromise?

Not for the vast majority of what a customer app does. Screens, navigation, forms, payments and notifications share almost all of their work across the two platforms, which is close to the cost of one app instead of two. Where a feature genuinely needs platform-specific code (heavy Bluetooth, background location, a custom camera, a watch app), we write native code for that piece only. If your product is mostly made of those features, we will tell you at scoping that shared code is the wrong choice.

What does it cost to run once it is live?

Three things: hosting for the backend, which we size to your real usage rather than to fashion; the developer accounts, where Apple's renews annually and Google's is a one-off; and the stores' commission on digital purchases, which does not apply to physical goods or services delivered outside the app. We model the hosting figure with your expected volumes during scoping, so you have a monthly number before committing.

Who owns the app, the accounts and the listings?

You do, and we set it up that way from the first day. The developer accounts are enrolled in your company's name with us added as a member, the source code sits in your repository, and our access can be revoked at any point without anything breaking. That is the practical test of not being locked in to a supplier.

What if nobody downloads it?

This is the real risk, and it is not a technical one. A listing in a store is not a distribution channel. Almost nobody will discover you by browsing. Downloads come from the customers you already have, which means the prompts have to live on your website, in your receipts and emails, on the counter, and anywhere else the customer already meets you. We build those in from the start and measure them, so the first month tells you whether the route to install is working rather than leaving you to guess.

Tell us what your regulars keep doing

Describe the thing your repeat customers do most often: order, book, check, collect. We will tell you honestly whether an app makes it meaningfully easier, and what a first version would take.

Start the conversation →

Explore more

The rest of Mobile Apps

Staff & field apps Website-to-app App Store launch ← All of Mobile