Mobile App Backend Development
A mobile backend has a constraint web backends do not: the client is a version you cannot update, on a network that is not there, held by someone who has closed the app.
- Typical duration
- Three to nine months
- Team shape
- Two to four senior engineers
- Starts with
- A sync contract review
Old app versions never go away
On the web, a bad deploy is undone in minutes and everyone is on the new version by lunchtime. On mobile, a version you shipped eighteen months ago is still installed on somebody's phone, still making requests, and still expecting the response shape it was built against.
That single fact drives most of what makes a mobile backend different: an API that is additive rather than mutable, a versioning policy decided before the first release rather than after the first break, and a sync contract that both platforms implement identically. Get those wrong and every future feature is negotiated against the oldest client still in the field.
What usually goes wrong, and what we do instead
Almost every difficult mobile backend problem is a versioning or a sync problem.
Where mobile backends get painful
- A response shape changed in place, breaking every installed old version
- iOS and Android implementing the same sync slightly differently
- Retries that duplicate records because writes are not idempotent
- Push notifications sent without a record of what was delivered
- Payloads sized for a desk connection rather than a rural one
How we build it instead
- Additive API changes only, with a written deprecation policy
- One sync contract, specified once and implemented the same on both
- Idempotency keys on every write, so a retry is never a duplicate
- Delivery and engagement recorded per notification, not assumed
- Payloads and pagination sized for the worst connection you support
What we build
The parts of a mobile backend that decide whether the apps stay simple.
Versioned APIs
Additive by default, with a deprecation policy agreed before the first release rather than after the first break.
Sync contracts
One specification of what syncs, when, and who wins a conflict — implemented identically on both platforms.
Authentication
Token lifetimes, refresh and revocation designed for a client that is offline for days at a time.
Push infrastructure
APNs and FCM behind one interface, with delivery recorded rather than assumed.
Data and media
Pagination and payload sizes chosen for the connection your users have, and resumable uploads.
Observability by client version
Errors and latency broken down by app version, so a regression is attributable in minutes.
What you end up with
Stated from your side rather than ours.
Two apps that agree
One sync contract implemented identically means a bug is in one place rather than being two different bugs.
Releases that do not strand anyone
Additive changes and a written deprecation policy mean an old installed version keeps working until you decide otherwise.
Support that can see what happened
Errors broken down by client version and device, so 'it does not work on my phone' becomes a query.
A backend your team can extend
Documented decisions, generated API reference, and infrastructure in accounts you own.
How the build runs
The same five stages as every engagement, applied to the services behind an app.
Diagnose
What the apps need, what the network is like where they run, and what old versions are still in the field.
Decide
The sync contract, the versioning policy and the auth model, written down before either app is built against them.
Prove
One path end to end from both platforms, including its offline case, its retry and its conflict.
Deliver
Services built in slices, each instrumented by client version before the next is scoped.
Hand over
Your team runs it with us watching, then without us.
What we build it with
Chosen for what a service has to survive when its clients cannot be updated.
Services
- Node.js
- TypeScript
- Java
- Spring Boot
- Go
Interfaces
- REST
- GraphQL
- Kafka
- Firebase
Data
- PostgreSQL
- MongoDB
- Redis
- Elasticsearch
Platform
- AWS
- Google Cloud
- Docker
- Datadog
- Sentry
What you get, and when
Handed over as it is produced, not assembled at the end.
- The sync contract, specified once for both platforms
- The API versioning and deprecation policy
- The auth model, including what happens after a week offline
- Source in repositories you own
- Infrastructure as code, in your accounts
- API reference generated from the schema, so it cannot drift
- Dashboards broken down by app version and platform
- Alerts with the runbook each one points at
- A record of which client versions are still supported
The rest of our mobile work
A mobile engagement rarely stops at one of these. These are the ones next to it.
Where we have built this
Sectors where the app is the interface and the services behind it carry the weight.
Fintech & BFSI
Secure, reliable systems for businesses built on trust.
We build and modernize financial platforms, workflows, integrations, and customer-facing applications where reliability, data integrity, auditability, security, and performance are fundamental to the business.
Fitness
Digital products designed to turn engagement into progress.
We create fitness platforms supporting member experiences, scheduling, subscriptions, progress tracking, coaching workflows, administration, and integrations, with usability and continued engagement at the centre.
Food & Travel
Digital experiences that keep customers and operations moving.
We build customer journeys and operational platforms around ordering, booking, marketplaces, partner integrations, administration, and real-time workflows where experience and operational efficiency need to work together.
HRMS
Workforce systems built around how organisations actually operate.
We build and improve workforce platforms spanning recruitment, onboarding, employee management, attendance, operational workflows, reporting, and integrations, reducing friction across the employee lifecycle.
Related work
Engagements where the apps and the services had to be designed together.
Questions about mobile backends
The ones we are asked most often before a first conversation.
Could we just use Firebase or a similar backend service?
We have a web API already. Can the apps use it?
Should iOS and Android share one API?
How long do we have to support old app versions?
Who wins when two devices edit the same thing offline?
Will it handle our user numbers?
Apps that need something solid behind them?
Tell us what the apps have to do offline. We will tell you what that means for the sync contract.