Mobile App Development
One codebase, two stores, and a release process that does not frighten anyone.
Tell us what the work has to do and we will scope it — including whether this is the discipline you actually need.
Request a quoteThe hard part of a mobile app is rarely the first build. It is the twelfth release, eighteen months later, when the person who wrote it has left and Apple has changed a requirement.
So we treat the release pipeline as a deliverable, not as our own private tooling. When we hand over, your team can ship without us.
Before we write code
We build a clickable prototype and put it in front of real users — usually five is enough to find the flaw that would have cost a month. Prototypes are cheap. Rewrites are not.
What we handle
Store submission is included, and so is arguing with the review process when it goes sideways. Crash reporting and analytics are wired in from the first build, because a bug you cannot see is a bug you cannot fix.
We also decide, deliberately, how much of the app should be offline-capable. In a market where connectivity drops between one district and the next, an app that fails closed is an app people delete.
Questions
Flutter for most products — one team, one codebase, and a UI that looks deliberate on both platforms. We go native when the app depends on something the platform guards closely: heavy background location, deep camera control, complex widget extensions. We tell you which case you are in during discovery, not after.
You do. The apps are published under your organisation's developer accounts. We set those up with you if they do not exist yet, and we never hold the signing keys hostage.
You get a signed CI pipeline — push a tag, get a build in both stores' review queues. We document the whole path, including what to do when a review is rejected.
Tell us what is not working.
A quote takes about five minutes to request and we reply within two working days — with a real assessment, not a brochure.