Android apps built for the phones your users actually own
Not the newest flagship on a designer’s desk. The three-year-old mid-range handset with a cracked screen, a full storage bar and a battery manager that shuts your app down while nobody is looking.
In short: We build native Android apps in Kotlin and test them across the spread of screens, OS versions and manufacturers your users really have. Device variety is a real cost in the budget, not a footnote in the proposal, and background features get proven on physical handsets from the makers most likely to interfere with them.
One platform, an enormous range of hardware
Android is one operating system in the same way that a road is one surface. Your users are spread across screen sizes from small phones to tablets and folding devices, across several OS versions still in daily use, and across manufacturers who each modify the system in their own way. An app that only ever ran on a recent Pixel has been tested against the easiest case there is.
Kotlin and Jetpack Compose
Current Android tooling, with the architecture components that keep state alive through rotations, low memory and the system killing your process.
Layouts that survive real screens
Narrow phones, tablets, split screen, foldables and large system font settings. Adaptive layout is cheaper to build in than to retrofit.
A deliberate minimum version
We look at who is in your analytics, pick the oldest version worth supporting, and tell you what each older step back costs to keep.
Built for mid-range hardware
Startup time, memory use and download size are tuned against modest devices, because that is where most installs land and where slow apps get uninstalled.
Battery managers will quietly kill your background work
This is the Android problem that catches out the most teams. Google’s own power saving rules are documented and predictable. Several manufacturers add their own layer on top, and that layer is more aggressive, less documented and different from one brand to the next.
The effect is that a sync, an upload, a location trace or a scheduled reminder can work perfectly for months in development, then simply stop happening on a particular handset after the user leaves the app alone for a while. No crash. No error in your logs. The work just never runs, and the first you hear about it is a support ticket saying the app is unreliable.
The fix is not clever code. It is knowing which brands do this, using the scheduling APIs the way the system wants them used, choosing a foreground service where the work genuinely warrants one, and telling the user plainly when a device setting is standing in the way. Then testing it on physical devices from those makers, with the app backgrounded for hours, before anyone promises a customer that reminders arrive on time. If a background feature is central to your product, we treat that testing as part of building it rather than as a quality assurance task to squeeze in later.
Device variety is a cost, and we price it as one
Every proposal has to answer one question honestly: which devices does this app have to be correct on? The answer sets the testing budget. A consumer app aimed at a broad market needs a wider matrix than an internal tool where the company issues one model to everyone, and those two projects should not be quoted as if they are the same job.
We build the matrix from your analytics where you have them, or from the market you are selling into where you do not. Common models get physical hardware. The long tail gets automated runs across a device farm. Camera behavior, keyboards, notification handling and back gestures all vary between manufacturers, and they are checked rather than assumed. This is not thoroughness for its own sake. It is the difference between a one-star review that says it does not work on my phone and one that never gets written.
Releasing without betting the whole user base
Google Play lets you release to a small share of users first and grow it as the numbers hold up. We use that on every production release. A build goes out to a fraction of your installs, crash rates and error reports are watched against the previous version, and the rollout only widens when the data says it should. If something is wrong, the release is halted before most people ever see it.
Around that sit the internal, closed and open test tracks, the pre-launch report that runs your build on real devices before release, and the stability metrics Google uses to judge how your app is doing. Play also expects your data safety form to match what the app really collects, so that gets rewritten whenever the data flowing to your backend changes, not once at launch.
What we won’t do
We won’t ship background features tested only on a Pixel
If reminders, sync or tracking matter to your product, they get proven on real handsets from the manufacturers known to interfere with them. If that hardware is not available to us, we say so rather than quietly assuming it works.
We won’t push a release to everyone on day one
Staged rollout exists so a bad build reaches a small group instead of your whole user base. Skipping it to make a launch feel bigger trades a real risk for a feeling.
We won’t support ancient Android versions just to sound generous
Each extra version back adds code paths, test runs and bugs. We show you what share of your users it actually covers, and usually recommend spending that money on the devices people are holding today.
Which phones does your app have to be right on?
Tell us who your users are and what the app has to do while it is not on screen. We will come back with a device matrix and what it costs to cover it properly.
Why do our notifications arrive late on some phones but not others?
Usually a manufacturer battery manager. Several brands add their own power saving on top of Android’s and it can stop scheduled work or delay delivery once the app has been idle. The answer is using the system scheduling APIs correctly, choosing the right kind of service, and testing on those brands directly.
How many devices do you test on?
It depends on your audience. We build a matrix from your analytics or your target market, put physical hardware behind the common models, and use automated runs on a device farm for the long tail. The matrix is agreed with you before the build starts.
What Android version should we support back to?
We look at who is actually using your product rather than picking a number. Each older version you keep adds code paths and testing, so we show what share of users it buys you and let you decide with the cost in front of you.
Can you take over an existing Android app?
Often, yes. We start by reading the code, the dependency list and the crash data, then tell you plainly whether it is worth continuing or whether the honest recommendation is a rebuild.
