Most apps fail quietly.
Usually before a line of code.
Apps do not fail because the engineering was poor. They fail because nobody validated that people wanted the thing, or because nobody planned how it would be found and kept alive after launch. We build for both.
What an app engagement covers: architecture, release pipeline, store presence and the stability targets that decide whether people keep it installed.
The riskiest decision is which features do not get built
Nearly every failed app we have reviewed was built to a specification agreed before anyone tested whether the core action was useful. Scope is where budget dies: teams build twelve features, discover users only want two, and have no money left to make those two excellent.
- “We need it on iOS and Android at launch”
- “It should have a social feed and messaging”
- “Users will log in with everything”
- “Can it work offline as well?”
- “We want to launch with all the features”
- Whether the core action is worth opening an app for rather than a website
- How fast the app opens and whether it works on a poor connection
- How someone finds it in a store with millions of competing listings
- What happens on day two, when the novelty has gone
- Whether you can afford to keep maintaining it after launch
The question we ask first: does this need to be an app at all? A responsive site or progressive web app is cheaper, instantly accessible and needs no store approval. We have talked clients out of apps, and it is usually the most valuable advice in the engagement.
What you actually receive
App projects go wrong when scope is vague. Everything below is agreed in writing before development starts, and you own all of it.
| Deliverable | Format | What it is for |
|---|---|---|
| Product definition | Document | The core action, the audience and the measure of success — written down so scope changes can be judged against something. |
| User flows | Diagrams | Every path through the app including error, empty and offline states, which is where most rework originates. |
| Interactive prototype | Figma | A clickable version to test with real users before development, when changes still cost hours rather than weeks. |
| Design system | Figma + code | Platform-appropriate components so the app feels native on each system rather than like a web page in a frame. |
| Application build | Source repository | iOS and Android builds with a typed API layer, offline handling and a documented architecture. |
| Analytics & events | Instrumented build | Funnel and retention events defined before launch, because retrofitting analytics loses the first cohort of data permanently. |
| Store listings | Copy + assets | Titles, keyword fields, descriptions and screenshots built for store search, which is how most organic installs happen. |
| Release pipeline | CI configuration | Automated build, test and distribution so updates ship in hours rather than requiring a manual ceremony. |
| Crash & performance monitoring | Dashboard | Live visibility of crashes, cold start and API failures, so problems surface before reviews do. |
| Handover pack | Docs + accounts | Source, signing certificates, store accounts and architecture notes transferred to you, with a recorded walkthrough. |
A first release should be deliberately narrow. We would rather ship a small app that works excellently and expand it with real usage data than launch a wide one nobody finishes onboarding.
Five stages, validated before they get expensive
Each stage exists to kill bad assumptions while they are still cheap to kill.
What the app must do, for whom, and whether it needs to be an app rather than a website.
Clickable flows tested with real users before any code, where changes cost hours instead of weeks.
Iterative development in two-week increments with a working build you can install at the end of each.
Store submission, listing optimisation, analytics verification and a staged rollout to catch issues small.
Retention and funnel data reviewed against the original success measure, then the next increment scoped.
What we hold every build to
Apps are judged publicly and permanently. A one-star review from a crash on launch week outlives almost everything else you do.
Monitored from day one with alerting. Store ranking, review scores and retention all degrade sharply with instability, and reviews left during a bad week are effectively permanent.
Measured on a mid-range device rather than the newest phone. Slow launch is the most common reason an installed app quietly stops being opened.
Offline states, retry logic and cached content designed in from the start. Apps that assume good connectivity fail exactly when people most need them to work.
Funnel and retention events instrumented before release. Adding analytics later permanently loses the data about your first and most informative cohort.
Title and keyword fields drive most organic installs. A listing written as marketing copy rather than for store search wastes the cheapest acquisition channel you have.
Developer accounts, signing certificates and source in your name. Apps published under an agency account are genuinely difficult to recover if the relationship ends.
Four shifts in mobile
The economics of apps have changed considerably. These shape what we recommend building.
React Native and Flutter now produce apps most users cannot distinguish from native, at meaningfully lower cost. Native still wins for heavy graphics, sustained background work or deep hardware access.
Organic browsing has largely collapsed. Installs come from store search, existing audience and paid acquisition, so a launch plan matters more than the build.
Attribution is far less precise than it was. Owned channels and store search have become more valuable relative to paid install campaigns, which are harder to measure honestly.
Progressive web apps now handle push, offline and installation. For content and booking use cases they frequently make more sense than a store app, and cost far less to maintain.
Three app engagements, three different lessons
Composite scenarios drawn from situations we see repeatedly — they illustrate method, not the account of any single named client.
The targets we set for an app build
Stability and speed targets agreed in the proposal and monitored publicly after launch.
These are planning targets rather than a record of past client averages; we agree a realistic range against your own baseline before an engagement starts. Retention and install numbers depend heavily on the product itself — engineering can make a useful app succeed, but it cannot make an unwanted one work, and we will say so during validation rather than after launch.
What clients ask before commissioning an app
Honest answers on cost, platform choice and whether you need an app at all.
Often not. Apps make sense when people use you repeatedly, when you need device features like camera or location in the background, or when offline use matters. For occasional use, content or a single booking, a fast responsive site does the job with no install friction and no store approval. We will tell you if that is your situation before taking a build budget.
Cross-platform for most business apps — one codebase, meaningfully lower cost, and quality users generally cannot distinguish. Native when you need sustained background processing, heavy graphics or deep platform integration. The decision should follow the product, and we will explain the trade-off rather than defaulting to whichever we prefer.
It varies enormously with scope, which is exactly why we validate scope first. What inflates budgets is rarely the core feature; it is authentication, payments, integrations, admin tooling and the long list of features added because they seemed cheap. Narrowing the first release is the single most effective way to control cost.
Twelve to twenty-four weeks for a focused first release. Store review adds days, not weeks, but rejections happen and are usually about privacy declarations or incomplete listings, so we prepare submission materials well before the build finishes.
Mostly store search and your existing audience. Organic browsing has largely disappeared, so the store listing matters more than most teams expect — title and keyword field especially. We treat the listing as a search problem, and it is included rather than being an extra.
You do. Developer accounts are created in your name, signing certificates are yours, and source is handed over with documentation. Apps published under an agency account are genuinely hard to recover, and we consider that arrangement unacceptable regardless of how the relationship ends.
Both platforms release annual updates that break things, so an unmaintained app degrades within a year or two. We monitor crashes and performance, and scope iterations against real retention data. If you would rather maintain it in-house, the handover is built to make that genuinely possible.
Thinking about building an app?
Tell us what you want it to do. We will tell you honestly whether it needs to be an app, what a validated first release looks like, and what it would cost.