We start by checking whether a well built mobile site solves the same problem at a fraction of the budget. If the answer is that you do need an app, we build it to last, with the maintenance cost stated from day one.
It is persuading somebody to install it. A visitor lands on your website and uses it immediately. To use your app, they have to go to the store, search, download tens of megabytes, wait for installation, and possibly create an account. At every step you lose a share of people, and the total loss is large.
It is worth going through that when the relationship is repeated. A delivery app you open weekly, a tool you use daily at work, a service where the notification is the value itself. In those cases the installation effort pays for itself.
It is not worth it when the interaction is rare. A firm you call once a year, a shop you buy from occasionally, a services brochure. Here the app is downloaded by a few friends and settles at a hundred installs, half of which are removed in the first month.
If it emerges from the conversation that you do not need an app, we say so, even if it means a much smaller project for us. We are not interested in selling a five month project you regret in year two, when the maintenance invoice arrives for something thirty people use.
| Option | When it makes sense | What it involves |
|---|---|---|
| Mobile optimised website | Rare interaction, content or simple selling | Cheapest and fastest. No installation, no stores, no separate maintenance. For many businesses it is the right answer |
| Installable web app | You want an icon on the home screen and partial offline operation, but do not need deep phone features | A single codebase for everything. Installs directly from the browser, no stores. Notifications work, with limitations on iOS |
| Cross platform app | The usual case when you genuinely need an app | Android and iOS from one codebase, with access to camera, location, notifications and local storage. Cost and timeline close to half of native |
| Native app | Intensive graphics, real time image processing, deep operating system integration | Two codebases, two teams, twice as much to maintain. Rarely justified, but when it is, there is no substitute |
Almost every app needs one: user accounts, data synchronised across devices, notifications sent, payments processed. It is often half the project and the part most frequently forgotten at estimation time.
We build it with versioned interfaces, so an old app on somebody's phone keeps working after you publish a new version. Without versioning, every server update breaks the apps people have not yet updated.
Apps are tested in an office, on fast internet and on new phones. They are used in a lift, on the underground, with a weak signal, on a five year old phone with twelve percent battery.
We explicitly handle what happens when the connection drops halfway through an action, what is saved locally so nothing is lost, how synchronisation resumes, and what the app looks like when it has no data. These are the situations that decide whether somebody opens it a second time.
The stores now require explicit declarations about what data you collect and why, and a wrong declaration means rejection or, worse, removal of the app after publication.
We collect strictly what is necessary, request permissions at the moment their purpose is understood, encrypt what is kept on the device, and prepare the declarations correctly the first time.
Publishing a version does not mean everyone has it. Users update when they feel like it, so you will always have three or four versions in circulation simultaneously.
We build so older versions keep working, with the ability to force an update only when a change genuinely requires it. Plus error tracking from the field, so you learn about a problem from a report rather than from a one star review.
Who uses it, how often, what it gains over a website. If the answer here is weak, we stop and tell you.
A single use case, taken all the way through. Everything that can be deferred is deferred. A bloated first version delays learning by months.
The screens and the routes between them, tested on people before any code. Here you fix cheaply what costs weeks in code.
Test builds on your team's phones every two weeks. You hold it in your hand early and often.
Different screens, different system versions, old and slow phones. Plus the poor connection situations that never occur in an office.
Accounts, materials, privacy declarations, submission and handling the review comments. We take care of the process.
An app cannot be left alone, unlike a website. Android and iOS release major versions every year, and the stores impose deadlines by which you have to comply or the app is withdrawn from sale. Plus expiring certificates, libraries with vulnerabilities and a server that has to be paid for monthly. We put the figure on the table before you sign, not in year two.
It is the first question we ask, and often the honest answer is no. An app makes sense when people use it repeatedly, when you need notifications, camera, location or offline operation, or when the customer relationship is continuous. If somebody would use you twice a year, a good mobile site does the same job at a tenth of the budget and without persuading anyone to install anything.
Cross platform for most cases: a single codebase for Android and iOS, so cost and time are close to halved, and performance today is sufficient for almost any app that is not a game or heavy image processing. Native where it genuinely matters. We tell you which your case is and why, with arguments you can verify.
A first working version, solving the main case, normally means three to five months. Cost depends on how many distinct flows the app has and how much of the server side already exists. We do not give figures before understanding, because an estimate produced in five minutes is either far too high to cover us, or too low and it becomes your problem later.
We handle it: developer accounts, store listing materials, the declarations about collected data, test builds for your team. A first App Store submission is rejected more often than people expect, usually for procedural reasons. We anticipate and address those in advance, but mentally budget two weeks for this step.
An app has a recurring cost a website does not. Android and iOS ship new versions every year, and the stores impose deadlines by which you have to comply or the app is removed. Plus server infrastructure and fixes. We tell you from the start roughly what that means annually, so it is not a surprise in year two.
We tell you honestly whether you need one and, if so, what it means in budget, time and annual upkeep.