Android App Development
Android is not one device. It is a distribution, and the interesting engineering happens at the older, cheaper, slower end of it.
- Typical duration
- Four to ten months
- Team shape
- Two to four senior engineers
- Starts with
- A device profile review
Build for the device your users have, not the one you have
An app that is quick on a current flagship tells you almost nothing. The devices that decide whether people keep using it are three years old, low on storage, on a throttled connection, and running an OS version two behind.
So the first thing we establish is the actual device and OS distribution of your users, and we test against the bottom of it rather than the top. After that the work is conventional and mostly about restraint: Jetpack rather than a bespoke framework, background work that survives the manufacturer's battery optimisation, and a defined answer for what the app does when the connection goes.
What usually goes wrong, and what we do instead
The pattern is consistent enough that we now check for it in the first week.
Where Android builds get expensive
- Tested on two recent handsets, so the real device range is a surprise
- Background work killed by a manufacturer's battery optimisation
- Offline treated as an error rather than a normal state
- A target API level left behind until the store enforces it
- Permissions requested on launch, before the user knows why
How we build it instead
- The real device and OS distribution established before any design
- Background work built on WorkManager and tested against restrictions
- Offline designed as a normal state, with a sync rule per data type
- Target API tracked continuously, so a deadline is never news
- Permissions asked for at the moment they make sense to the user
What we build
The parts of an Android app that decide whether it stays installed.
Kotlin and Jetpack Compose
Built on the platform's current patterns, with Views where a screen genuinely calls for them.
Offline and sync
A defined answer for no signal, and a conflict rule per data type agreed before it is built.
Device range
Tested on the hardware your users actually carry, including the slow end of it.
Security
Encrypted storage, biometric authentication and a data safety declaration that matches the code.
Background and notifications
Work that survives battery optimisation, and notifications designed around what earns attention.
Platform surfaces
Widgets, share targets and deep links where they carry real weight rather than as a checklist.
What you end up with
Stated from your side rather than ours.
An app that works on cheap phones
Because the device profile came first, the hardware most of your users carry was the target rather than the exception.
Something that works underground
Offline is a designed state with agreed conflict rules, so a lost signal does not lose work.
No scramble at a policy deadline
Target API and data safety are tracked continuously, so a Play Store requirement is already met when it lands.
A codebase your team can take on
Conventional Kotlin, documented decisions and a pipeline that builds and ships without us.
How the build runs
The same five stages as every engagement, applied to an Android app.
Diagnose
Who uses it and on what, the real device and OS spread, and what has to work with no signal.
Decide
Architecture, the offline data set and the minimum supported device, written down with what each costs.
Prove
One workflow end to end on the slowest supported handset, offline and back, released to a test track.
Deliver
Features built in slices, each released to internal or closed testing before the next is scoped.
Hand over
Your team ships a release with us watching, then without us.
What we build it with
Chosen for what an app has to survive across a wide range of hardware.
Application
- Kotlin
- Jetpack Compose
- Coroutines
- Hilt
Data on device
- Room
- SQLite
- DataStore
- WorkManager
Services
- Node.js
- TypeScript
- PostgreSQL
- Firebase
Delivery
- Gradle
- GitHub Actions
- Google Cloud
- Sentry
What you get, and when
Handed over as it is produced, not assembled at the end.
- The device and OS distribution, measured rather than assumed
- The minimum supported device, with what supporting it costs
- The offline data set and a conflict rule per data type
- Source in repositories you own
- A signing and release pipeline in your Play Console
- Builds to an internal test track from the first slice
- A data safety declaration that matches what the app collects
- Crash, ANR and performance dashboards with alerting
- A release runbook your team has used at least once with us
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 phone goes where the work is, and the work is not at a desk.
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.
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.
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.
Healthcare
Technology that connects complex care and operational workflows.
We help build digital healthcare platforms, operational workflows, integrations, and data-driven applications designed around reliability, secure information handling, usability, and the realities of interconnected healthcare systems.
Related work
Engagements where the product lived on hardware we did not control.
Questions about Android work
The ones we are asked most often before a first conversation.
Should this be native or cross-platform?
Which devices and OS versions will you support?
What happens when Google raises the target API requirement?
Our background sync stops working on some phones. Why?
Do you build the backend too?
Can our team take it over afterwards?
Building for Android?
Tell us who uses it and on what. We will tell you what that means for the build.