Be Aware of These 8 Tips From Expert App Developers

Apps fail quietly. The store listing goes live, a handful of people download it, and then nothing, no retention, no word of mouth, no second session. The product looked finished. The features were all there. But something in the way it was built, or scoped, or researched, or presented to users, made it feel wrong at the right moments and users left. We have worked on enough of these products, and rescued enough of them mid-build, to know that the failures are almost never random. They follow patterns, and those patterns are avoidable.

The failures are almost never random, they follow predictable patterns that competent teams can avoid.

What follows is not a checklist of generic best practices. Each point comes from something specific, a project that went wrong in a particular way, a decision that cost a real amount of money, a finding that changed how we approach a certain type of problem. Some of these are things we got right. Others are things we watched go badly wrong despite giving clear warnings. All of them are things that shape how we work now.

Eight principles run through all of it, and each one is worth understanding before you spend a pound on development.

Run Discovery on Every Feature, Not Just the Ones You Care About

Discovery is the part of the process that most clients want to skip. It feels like delay when you already know what you want to build. But the danger is in skipping discovery on the features you assume are obvious.

We worked on a dating app built around verified profiles and preventing bots. The client invested heavily in discovery for the onboarding process, and the result was rigorous. But the client chose to skip discovery for the messaging component entirely, reasoning that messaging was straightforward and well understood. What got built was a generic messaging feature that allowed automated and fake messages, the exact behaviour the onboarding was designed to prevent. The verified onboarding and the permissive messaging were in direct contradiction with each other. Fixing it required a complete rewrite of the messaging section, at a cost of approximately £15,000 in additional budget and two months of extra work.

The lesson is not that messaging is complicated. The lesson is that skipping discovery on any interconnected component creates gaps, and gaps in a product's logic are expensive to close after build. Product coherence requires discovery across all the parts, not just the ones a client prioritises. Features do not work in isolation, they create expectations for the features around them, and when those expectations are not met, users feel it even if they cannot name it.

Before build begins, map every feature in the product and ask whether discovery has been run on each one. If any are marked "obvious" or "standard", treat that as a flag rather than a reason to skip.

Launch Less, Launch It Well

The most common reason a product never reaches market is scope. Founders arrive with a vision that grows during the build process, each addition feeling necessary and each delay feeling temporary. The product becomes something no single sprint could ever deliver, and the budget runs out before anything ships.

We worked on a grassroots football club app where the client's intention was, in effect, to combine several different apps into one product. We recommended repeatedly that they focus on releasing a limited feature set first, test the market, gather data, and grow from there. The client disagreed. The scope kept expanding, the budget kept rising, and the product never launched. The complexity it reached was unnecessary. Every feature that was added felt individually justified, but collectively they made the thing unlaunachable.

A separate but related point: 88 per cent of users are less likely to return to an app after having a bad experience. That figure makes the case for restraint more clearly than anything else. Delivering ten features at a mediocre standard gives users a bad experience across ten surfaces. Delivering three features exceptionally well gives users a reason to come back. The budget is finite and execution quality matters more than feature count.

The MVP Mindset

An MVP is a complete product with a deliberately limited scope. The features it contains should work without fault. What it does not contain should be absent by design, with a clear plan for what comes next.

Treat Research as a Decision-Making Tool, Not a Formality

Research only changes outcomes if the people commissioning it are willing to act on the findings. When a founder has already made up their mind, research becomes a performance, something done to satisfy a process rather than to inform a decision.

We worked with a founder who had deep industry experience and very strong pre-existing views about how the product should work. The research process ran, focus groups were conducted, surveys were completed, and the data came back with compelling evidence: a large portion of the target user base did not want certain features and preferred alternatives. The founder dismissed it. The findings did not move a single decision. Our team eventually walked away from the engagement. The product launched approximately a year later, largely unchanged from what the founder had originally envisioned, and by every account we have seen since, it failed, for the same reasons the research had identified.

We also identify this pattern across a fitness and wellbeing app and a grassroots football product, where founders with strong personal conviction ignored data coming from research studies and focus groups. The product becomes what we call a vanity product: shaped by the founder's preferences rather than user evidence. Early warning signs include an excessive drive to perfect the product before launch, rolling back sign-offs to request further changes, and prolonged decision-making. Both projects exhausted their budgets in design and build without ever reaching a fully live product.

Business of Apps puts the figure at 42 per cent of apps failing because they were launched without prior market research. What the data cannot capture is the number that ran research and then ignored it, which in our experience is the more expensive failure mode.

Match Your Interface to the User's Mental and Emotional State

An interface is a communication between the product and the user's current state of mind. When the product asks too much of a user who is stressed, confused, or overwhelmed, the user fails the task and blames the product.

We were developing a pitch for BMW, looking at one of their companies that handles fleet and rental vehicles. The existing app required accident victims to record damage and complete forms immediately after a collision. The interface simply said "upload your photos, " with no guidance on what angles to capture or what information mattered most. Users were not completing the process correctly, and the product team could not understand why.

Asking too much of a stressed user does not reveal their limitations, it reveals a design failure.

The answer was straightforward once you put yourself in the user's position. Someone who has just had an accident is not in a calm, focused state. Their cognitive load is already at its limit. An interface that expected them to know what documentation was needed and how to provide it was setting them up to fail. The solution was to guide users through each step explicitly, what photo to take, from which angle, and why, reducing the cognitive demand to the minimum the task actually required.

The principle applies across product categories. A healthcare app asking patients to complete long assessments in a waiting room, a travel app presenting complex pricing to someone booking under time pressure, both situations call for an interface that meets the user where they are, not where the team assumes they will be.

Before finalising any key user flow, describe the emotional and cognitive state the user is likely to be in at that exact moment. If the flow assumes calm and focus, test it on someone who is under pressure.

Show Users More Information, Not Less

The instinct to simplify is usually correct, but simplification is not the same as hiding information. Users are reassured by understanding what is happening. When information is absent, users do not assume everything is fine. They assume something is being concealed.

On a travel booking product we worked on, we initially decided to wrap the platform's Stripe booking fee into the total price displayed to users. The reasoning was that travellers want to see one clean total, and breaking out fees would add visual noise. What we found in practice was the opposite. Users expected to see a platform fee as a line item, because that matches how they understand apps and platforms to work. By not showing it, we created a fear that a hidden fee would appear at the payment stage. Users were less confident, not more.

When we switched to breaking all fees out transparently, showing exactly what each component of the total consisted of, user confidence increased, even though they were now looking at more information and more numbers. The transparency was itself the signal of trustworthiness. Showing more gave them more trust, not less.

What Transparency Communicates

The choice to show a fee breakdown is a signal about the product's relationship with the user. A product that hides nothing feels safer than one that simplifies at the cost of honesty.

Remove Friction Before It Kills Adoption

Friction in the early stages of a product journey does not frustrate users, it loses them. The decision to return to an app is made in the first session, sometimes in the first few minutes of it. A product that asks too much before it has given anything back will not get a second chance.

We worked on a surveying app for performance coaches, where the original design required audience members to download a native app in order to complete a survey after a presentation. From the coach's perspective, this seemed reasonable, the product was app-based, so the audience should be in the app. From the audience member's perspective, downloading an app to answer a few questions is a significant ask, and most people will not do it.

We recommended a different approach. The coach creates the survey in the native app as before, but instead of requiring the audience to download anything, a QR code appears on screen. Scanning it takes the audience member to a fully branded, mobile-responsive web page that behaves like an app without requiring one. The barrier to completion dropped substantially, and survey completion rates increased significantly as a result. The experience felt native without the friction of an app store download standing between the user and the task.

According to AppsFlyer mobile onboarding studies, users who experience friction in their first session are 2.7 times less likely to return by Day 7. That figure is worth holding in mind every time a product asks users to do something before they have been given a reason to.

Walk through your onboarding as a new user with no context and no motivation. At each step, ask whether the ask is justified by the value the user has received so far. If it is not, remove or delay it.

Build Trust Incrementally Before Asking for Sensitive Data

Sensitive data requests, location, contact information, payment details, health information, are only reasonable once a user has sufficient reason to trust the product asking for them. Ask too early, and most users will either decline or leave. The request itself becomes a signal that the product does not understand appropriate boundaries.

On a fitness social network we worked on, one of the core features was connecting users with nearby running partners. The natural implementation would have been to share location data between users who matched on interests and pace. But sharing precise location with a stranger is a genuinely high-stakes action, and most users in the target audience, particularly women running alone, were uncomfortable with it. Completion on that feature was low.

The solution was to sequence the disclosure. Rather than revealing a user's exact location, we displayed only an approximate proximity, within 200 to 500 metres, so that a potential running partner could see that someone was nearby without knowing where. The user could then view the other person's profile and exchange messages through a built-in chat function. Only after both parties had decided they were comfortable did the option to share precise location and arrange a meeting appear. The trust was built across a sequence of smaller, lower-stakes actions before the high-stakes one was requested, and adoption of the feature improved accordingly.

The Sequence Matters

The order in which a product asks for things is itself a communication. A well-sequenced product earns each request before making it.

Hold the Scope, Even When the Client Won't

Scope creep does not usually announce itself. It arrives as a reasonable request, then another, then another, and by the time the pattern is visible the budget is gone and the product is nowhere near launch. Part of a good development partner's job is to hold scope when the client is pushing against it, and to document clearly what the consequences will be if the advice is not followed.

On the sports club app project, the two co-founders were deeply embedded in the world the app was designed for, this was the business itself, not a peripheral tool, and they were emotionally and professionally close to every decision. Both founders consistently pushed to add more features. Each addition felt individually justified to them, and both were strong-willed enough to push back against scope boundaries. We warned the clients early that the budget would get wildly out of control if the pattern continued, and that they risked running out of funding before launching anything.

The warnings were noted but not acted on. The project ended with the entire budget exhausted, nothing published to the app store, and the client and agency parting ways. Every feature that was added during that period came at the cost of the launch itself.

Holding scope is about protecting the outcome the client actually wants. A product that ships with five features is infinitely more valuable than a product with fifteen features that never reaches users. The professional obligation is to say so clearly, put it in writing, and hold the position even when it is uncomfortable.

• Document scope formally and get sign-off at each stage.
• When a new feature is requested, show clearly what it costs in time and budget.
• Name the trade-off explicitly: this feature delays launch by X weeks.
• If a client continues to override advice, record that in writing.

Conclusion

None of these principles are complicated in isolation. Running discovery on every feature, launching less but launching it well, treating research as a real decision-making tool, these are straightforward enough as ideas. What makes them difficult is sustained application, especially under the pressure of a client who has a strong vision, a tight deadline, or a preference for moving fast.

The projects that go wrong almost always have a warning sign early on. A founder who dismisses research findings. A scope that keeps expanding past what the budget can support. An interface designed for the team's assumptions rather than the user's actual state. A trust-sensitive request appearing before the product has done anything to earn it. The warning is not always heeded, and the cost of ignoring it is usually paid late in the project when reversing course is expensive.

What we try to do at WAA is name those patterns early and hold a position on them consistently, even when that is an uncomfortable conversation. The goal is a product that reaches users, works well for them, and earns a reason for them to return. That outcome depends on decisions made long before the first line of code is written.

If your product is at any stage of that journey and you want to talk through where the risks sit, let's talk about your app.

Frequently Asked Questions