Mobile App Development
What we've learned so far
A mobile app earns its cost when it creates habit. It is the only channel that sits on a customer's home screen, works offline, and can reach them without paying a platform for the privilege. That is worth a great deal for products people use weekly, and worth very little for products they use twice a year, which is a conversation we prefer to have before the project rather than after.
An app is judged on the second open, not the first. We have shipped apps with clean installs and flat retention, and the cause was rarely the interface. Nothing had happened yet that made returning worthwhile, so we design the first session around getting a user to one real outcome and treat the rest as secondary. The platform is also part of the work: review cycles, permission prompts, push entitlements, background execution limits and store policy all sit on the critical path, and a team discovering them at submission loses a fortnight. We submit early and deliberately, before there is anything to lose by failing. Offline behaviour is the third thing, because a phone loses connection at the worst possible moment by definition.
Cross-platform tooling and generated code have made building an app dramatically cheaper, which means more apps and a higher proportion of them abandoned after a fortnight. The scarce thing is not the build. It is deciding whether an app is the right format at all, what single behaviour it should drive, and how it will earn a place on a screen that is already full.
What this can involve
Prototyping Services
Micro-interaction Design
User Flow Design
How we work
Understand the business, the market and the customer
How the product makes money, who it is for, what the alternatives already do, and how often someone would genuinely open this. That last answer decides whether an app is the right format at all.
Pick the one behaviour the first release has to drive
An app cannot launch with everything a mature competitor offers, and waiting until it can means arriving after the opportunity. We agree a single real outcome for the first version and design the whole first session around reaching it.
Deal with the platform early
Permissions, push entitlements, background limits and store policy sit on the critical path. We submit a build early and deliberately, while failing review still costs nothing.
Design for a phone that loses signal
Offline behaviour, sync conflicts and what the app does at the moment the connection drops, which by definition happens at the worst time.
Ship, watch the second week, then ship again
Installs tell you nothing. Return rate after a fortnight tells you whether the app earned its place, and what people actually do decides the next release. Apps that hold a home screen are built over several versions, not one.
Where this isn't the right fit
If people would use it a handful of times a year, build a good mobile site. An app that nobody opens still costs you store presence, OS updates and a release process, and it quietly becomes a liability rather than a channel.
If there is no budget beyond launch, reconsider. Both platforms change every year and an unmaintained app degrades whether or not anyone touches it. And if the app exists mainly because competitors have one, that is not a reason a customer will make room on their home screen.
