Mobile Apps (Android + iOS)
An Android or iOS app — worth building only when people will open it repeatedly, and honest about the store review that comes with it.
An app is a commitment, not a website with an icon. It has to be installed, it has to earn a place on a home screen, and it has to be released again through Google Play and the App Store every time it changes. That is worth doing when people use the thing often — a delivery rider every shift, a salesman on a route daily, a customer with a loyalty balance to check each week.
It is not worth doing for a business that needs to be found and contacted. Nobody installs an app to look up a phone number. If that is the need, the honest recommendation is a fast website, and we would rather say so than build something that is downloaded once and never opened again. Where an app is right, what gets built is scoped to the repeated task it exists for.
What it fixes
- Field staff working on paper and entering the day's work into a system that evening, if at all
- No way to work where there is no signal, so the data is always a day behind reality
- Phone features the job genuinely needs — camera for proof, GPS for location, scanning, notifications — unavailable to a browser-based process
- A workflow that staff abandon because it was designed for a desk and handed to someone standing up
- Updates that cannot be pushed to users, so several versions of a process run at once
- An app built as a shortcut to the website, installed by a few people, then left unopened
What gets built
A starting point, not a fixed list. The build is scoped to your own process before anything is written.
Scoped to one repeated job
Built around the task the app actually exists for — a collection route, a delivery run, a stock count — rather than a mobile copy of a whole system.
Works without a connection
Entries held on the device and synced when signal returns, with duplicate handling designed in. This is the part that is hard and the part that matters for field work.
Device features used properly
Camera, GPS, barcode or QR scanning and push notifications where the job needs them, with the battery and data cost considered rather than ignored.
Android and iOS from one codebase
Built cross-platform where that fits, so both platforms stay in step. Where a feature genuinely needs native work, we will say so instead of pretending it is free.
Store submission and release
Preparing listings, icons, screenshots and privacy declarations, submitting to Google Play and the App Store, and handling review feedback. This is real work and it is part of the engagement, not an afterthought.
Updates and versioning
A release process for later versions, including gracefully handling users who have not updated — because a meaningful share of them will not.
Who this is for
Businesses with a repeated, daily task on a phone: recovery and collection officers, delivery and logistics teams, field sales, inspection and survey work, and consumer businesses with genuine repeat usage such as loyalty or account balances. It is not for a business that mainly needs to be found, contacted or browsed — that is a website, and an app in its place is money spent on an icon nobody taps. Also not advisable before the underlying process exists: an app for a workflow that is not yet settled gets rebuilt.
Questions
Do we need an app, or is a website enough?
Usually a website, and we will tell you when that is the case. The test is simple: would the same person open this more than once a week for months? If not, an install is a barrier rather than a benefit. A fast mobile website reaches everyone immediately with no download and no store review.
How do Google Play and the App Store affect this?
Both review submissions, and both can reject one — commonly over privacy declarations, permissions, account deletion or incomplete listings. Apple's review is stricter and takes longer. Both also charge developer account fees and need those accounts in your own name. Every update goes through review too, so a small fix is not instant. We plan for this rather than treating a rejection as a surprise.
What does it cost to keep an app running?
More than a website, and that should be clear before you start. Developer accounts renew, the operating systems change every year and force updates, and devices your staff use will need testing. Budget for maintenance as an ongoing line, not a one-off build. If you cannot, a website is the sounder decision.
Tell us how your business runs.
We scope it first — what it takes, how long, what it costs. No obligation.