A mobile app is a much larger commitment than most companies expect when they first ask for one. The visible part — the screens — is perhaps a third of the work. The rest is the server behind it, the accounts and permissions, the release process, the two app stores with their own rules, and the ongoing obligation to keep it working as operating systems change underneath it.
Before any of that, there is a harder question to answer honestly.
Does this need to be an app at all?
Ask what the app does that a well-built mobile website cannot. There are good answers: it needs to work without a signal, it needs the camera or GPS continuously, it needs to send push notifications people will actually act on, it will be opened several times a week by the same person.
There are also weak answers, and the most common is that competitors have one. If the intended use is occasional — checking a statement every few months, browsing a catalogue — a responsive site will reach more people at a fraction of the cost, and nobody has to be persuaded to install anything. We have talked several clients out of an app and into a better mobile site, and none of them regretted it. Getting someone to install software is one of the hardest things to ask of a customer.
Decide who the users are and how they get in
Accounts drive a surprising amount of the build. Will people register themselves or be issued credentials by an administrator? Do you need social or corporate sign-in? What happens when someone forgets their password, changes phone, or leaves the company? Are there different roles — a field technician, a supervisor, a customer — with different permissions?
If the app is for staff, add device management to the list: company-owned or personal, what happens when a phone is lost, whether data can be stored locally on it. These decisions affect architecture, so making them late is expensive.
The backend is the actual project
An app is a window onto data that lives somewhere else, and building that layer is a custom software project in its own right. That somewhere else needs to be designed: the database, the API, the administration interface for your own team, the reporting, the notification service, the file storage for photos and documents.
In most of our projects this is the majority of the effort, and it is the part clients under-budget because it is invisible in a design mock-up. It is also the part that determines whether the app can be extended next year without rewriting it. If an existing system already holds the data, plan the integration properly rather than assuming a straightforward connection exists.
Offline behaviour must be specified, not assumed
Any app used away from a desk will lose connectivity. What should it do? Refuse to continue, queue the work and sync later, or show cached data with a warning that it may be stale?
Queuing sounds obviously right and introduces the hardest problem in mobile development: two people editing the same record from different devices, both offline. Decide the conflict rule in advance — last write wins, server wins, or flag for human review — because discovering it during testing usually means restructuring the data layer. For field service and delivery apps this is the single most important design conversation.
Budget for the second year
Apps are not finished at launch in the way a brochure website can be. Apple and Google release major operating system versions annually, and each one can break something or introduce a new store requirement. Certificates expire. Developer programme fees recur. Store review policies change and can reject an update you needed to ship urgently.
A realistic plan sets aside a maintenance allowance from the first year, independent of new features. Companies that skip this find themselves two years later with an app that no longer installs on current phones and a rebuild quotation they were not expecting.
Plan the launch as carefully as the build
Store listings need screenshots, descriptions, a privacy policy and a support contact. Internal apps need a distribution method and instructions written for people who will not read them. Either way, someone must own the release process, monitor crash reports and respond to reviews.
An app with no owner after launch decays quietly. One with a named owner, a small monthly budget and a habit of reading user feedback will still be useful in three years, which is the only test that matters.
