Included in a typical proposal
- Design and build for the named platforms and journeys.
- Assistance submitting the first version if listed in the proposal.
- A handover of the repository and signing setup.
SOFTWARE DEVELOPMENT
Create a mobile experience around a clear user need. Choose native or cross-platform delivery after considering devices, functions and the support the app will require.
WHAT THIS SERVICE IS
Mobile app development is a product people install on a phone or tablet to complete a job that a website handles poorly: camera, location, offline queues, store distribution, or a consumer habit of “there should be an app”. It is expensive to support compared with a browser tool, so the reason must be a real user need, not a competitor’s icon.
Native versus cross-platform is a choice after we know devices, offline rules, and who will publish in the Apple and Google accounts — accounts that must be yours. We will not publish a business app from a personal developer account that leaves with an employee.
Versioning, store review, and the fact that users do not update promptly are part of the operating model. A mobile app is not finished at first approval in the store.
A CLEAR PICTURE
WHO IT IS FOR
Businesses whose field staff cannot rely on a laptop, consumer products that need a store listing, and teams whose web app hit a genuine device limit.
TYPICAL SCOPE
Audience, platforms (iOS, Android, or both), and the journeys that justify an app. If a responsive website would do, we will say so and point you at web application work.
Navigation and screens for the device sizes you issue. Accessibility of tap targets and Dynamic Type where we can. We do not copy another app’s interface.
Agreed features, API connections, and offline behaviour you specified. Background work and battery use are constraints, not afterthoughts.
TestFlight or internal tracks, store listing assets you supply, and a plan for the next version. Store fees and legal questionnaires are yours to complete. We assist with the technical answers we can.
HOW THE WORK RUNS
Against a browser alternative.
Including poor network.
From the start.
With a way to fix it without waiting a month if the store allows a rapid path.
INCLUDED AND QUOTED SEPARATELY
AFTER HANDOVER
Signing keys, store access and the repo are on organisation accounts. A laptop with “the only keystore” is a risk we will refuse to leave as the steady state.
Each store update is a mini-release. Maintenance should describe how those updates are approved. Abandoned apps linger in stores and still show your name.
PRACTICAL NOTES
Push notifications require certificates, user consent, and a reason that is not “engagement”. We will not spam a field worker at night unless the brief says alarms are the job. Store policies on that topic change; your listing text must match what the app does.
Offline queues need a conflict rule: whose timestamp wins when the van comes back to signal. Without that rule, you get duplicate tickets. Write it down in discovery. It is cheaper than a year of “the app double-created the job”.
PLANNING THE WORK
We can technically. Stores and users treat that poorly unless there is a device-specific reason. We will not recommend it as a default.
It varies and is not a date we control. Build a buffer. This page does not quote a review SLA.
Only when named. Each extra store is extra packaging and extra review.
CONNECTED SERVICES
LET’S BUILD WHAT’S NEXT
Tell us what you want to improve, build or simplify. We’ll help you define a practical way forward.
Discuss your project