---
title: Build an App That Makes Your Business Money
description: Most apps fail to make money due to early decisions, not technology. Discover how retention, onboarding and revenue models shape whether your app succeeds.
image: https://weareaffective.com/hubfs/learning-centre-images/build-an-app-that-makes-your-business-money.webp
---

[Skip to content](https://weareaffective.com/learning-centre/build-an-app-that-makes-your-business-money#main-content)

[![we\_are\_affective\_logo\_200](https://weareaffective.com/hs-fs/hubfs/we_are_affective_logo_200.png?width=175&height=48&name=we_are_affective_logo_200.png "we_are_affective_logo_200")](https://weareaffective.com)

- [Home](https://weareaffective.com)
- About Us 
  
    - [Our Story](https://weareaffective.com/about)
    - [How We Work](https://weareaffective.com/how-we-work)
- Our Services 
  
    - [App Planning & Strategy](https://weareaffective.com/app-planning-strategy)
    - [App Design](https://weareaffective.com/app-design-agency)
    - [App UX Design](https://weareaffective.com/app-ux-design)
    - [App UI Design](https://weareaffective.com/app-ui-design)
    - [App Technical Architecture](https://weareaffective.com/app-architecture)
    - [Existing App Audits](https://weareaffective.com/app-audit)
- [Case Studies](https://weareaffective.com/case-studies)
- [Pricing](https://weareaffective.com/pricing)
- [Learning Centre](https://weareaffective.com/learning-centre)

- [Get Started](https://weareaffective.com/get-started)

Expert Guide Series

# Build an App That Makes Your Business Money

 Table of Contents

A lot of apps get built. Far fewer make money. The gap between those two things is not usually a technology problem, and it is rarely about having the wrong features. It is almost always about [decisions made early, often without enough thought](https://weareaffective.com/app-planning-strategy) for the person who will actually use the product.

> An app that attracts downloads but fails to hold attention past day three is a marketing exercise, not a product.

We have spent years working on apps across fitness, property, hospitality, and professional services, and the pattern is consistent. A product launches with real energy behind it, download numbers climb, and somewhere around day three the numbers quietly tell a different story. Retention falls. Revenue does not follow. The team keeps watching the wrong signals.

This article covers what actually moves the needle: how users form first impressions, why onboarding is a financial decision rather than a design one, when a native app is the wrong tool entirely, and how to build a revenue model that works with user behaviour rather than against it. These are not abstract principles. They come from real products, real decisions, and in some cases, real mistakes we helped clients avoid.

## Why the Majority of Apps Never Make Money

The most common assumption we encounter is that an app fails because of what it lacks: a missing feature, an underpowered back end, a competitor who launched first. The reality is usually the opposite. Apps fail because of what they include, and how little thought went into whether any of it was truly needed.

Teams build for an imagined user, one who is patient, curious, and arriving with time to explore. The actual user is busy, slightly sceptical, and [making a decision within seconds about whether this was worth downloading](https://weareaffective.com/learning-centre/what-curiosity-looks-like-in-a-first-session-and-why-most-products-design-past-i). Designing for the ideal user rather than the one who actually shows up is one of the most common patterns we flag in product audits. The design looks polished on a prototype; it falls apart the moment real behaviour enters the picture.

There is also a structural problem with how success gets measured. Download counts are easy to track and satisfying to report. Retention rates are harder to face, so they often get less attention. A product can look healthy from the outside while quietly losing the majority of its users in the first week. Revenue follows retention, so a product that cannot hold attention cannot build a sustainable income, regardless of how much is spent on acquisition.

## The Three-Day Drop: What the Retention Numbers Actually Mean

On average, 77 per cent of apps lose their daily active users within the first three days of download (according to [AppsFlyer mobile onboarding studies](https://sparklin.com/blog/why-users-abandon-apps-during-onboarding)). Even well-designed products typically see a 40 to 50 per cent retention drop over the same period. That gap between 77 per cent and 40 to 50 per cent is where the real commercial argument for good design lives.

We see teams focus on growing download numbers while giving very little attention to what happens afterwards. Downloads rise, which feels like progress, but the retention picture at day three, day five, and day seven tells a different story. [A day-one retention rate below 50 per cent](https://weareaffective.com/learning-centre/how-to-structure-a-behavioural-risk-register-before-you-write-a-single-user-stor) is borderline and should be treated as a warning sign, and the goal is to push users well past that, through day thirty and beyond, particularly when there is paid acquisition involved and that spend needs to be justified.

The other problem is silence. Users who have a poor experience rarely submit feedback or raise a complaint. They simply leave. That absence of noise can feel like approval, but it almost never is. Without actively tracking what happens to users across the first week, teams end up mistaking quiet churn for satisfaction.

## UX/UI design built around *real* psychology

We design app interfaces around how people actually think and behave. User research, psychology-driven UX/UI design and technical specs delivered as one complete package.

[See how we work](https://weareaffective.com/how-we-work) [Get started](https://weareaffective.com/get-started)

No commitment

## Before the Download: Getting Your App Store Listing Right

Most conversations about reducing abandonment focus on what happens inside the app. The store listing rarely gets the same attention, which is a mistake. The average visit to an app's product page lasts no more than ten seconds, with roughly half that time spent on screenshots, according to [SplitMetrics](https://splitmetrics.com/user-behavior-insights-app-store-vs-google-play/). That is an extremely short window in which to set expectations correctly.

A store listing that accurately describes what the app does, and who it is for, performs a kind of pre-screening. Users who download after reading an honest description already understand the product. They arrive with the right expectations, which means they are less likely to bounce when the reality matches what they were told. Early abandonment frequently comes from misalignment between the promise in the listing and what the app actually delivers on first use.

> Users who download with accurate expectations are far less likely to abandon in the first session.

This means the listing is not marketing in the traditional sense. It is not about making the app sound as appealing as possible. It is about attracting users who are genuinely the right fit, and filtering out the ones who would download, feel misled, and leave.

Write your app store description as a filter, not a pitch. If it attracts someone who would not benefit from the product, their download costs you a user without gaining you one.

## The First Three Seconds Decide More Than You Think

When a user opens an app for the first time, their brain is doing something rapid and largely unconscious. Within the first three seconds, it is forming a judgement about whether the product looks competent, trustworthy, and worth continuing with. The user does not consciously ask themselves "does this look professional?", but they feel the answer, and that feeling drives what they do next.

This is not a small effect. According to [PCloudy](https://www.pcloudy.com/blogs/app-performance-and-observability-key-to-retaining-users/), 53 per cent of users will abandon an app if it takes longer than three seconds to load. But the judgement is not only about speed. Visual quality, layout coherence, and the sense that someone thoughtful built this thing all register instantly. A product that looks unfinished signals incompetence before the user has read a single word.

#### What trust looks like at three seconds

Headspace is a useful example of this done well. Its opening screen removes the two things that most commonly break trust on health apps: a sign-up gate and a diagnostic questionnaire. There is no prompt asking how you are feeling today, which would presume an intimacy that has not yet been established. By asking nothing of the user upfront, the app removes both friction and the mild anxiety that early demands typically produce.

The lesson is that the [first screen should be designed around the emotional state](https://weareaffective.com/learning-centre/what-a-development-team-actually-needs-to-know-about-the-user-before-sprint-one) of the user who is actually arriving, the overwhelmed and distracted person rather than the calm and receptive user the team imagined during design.

## Onboarding as a Revenue Decision, Not a Design Detail

Onboarding is often treated as a UX nicety, something that should feel smooth and pleasant but is not really where the commercial stakes are. That framing is wrong. Research from [Amplitude's 2025 Product Benchmark Report](https://www.scribbl.co/post/client-onboarding-best-practices) found that 69 per cent of products with strong early activation were also strong three-month retention performers. The connection between getting users to value quickly and keeping them long enough to generate revenue is direct.

We worked on a fitness app where early abandonment was a real problem. One of the changes we made was simple: we told users upfront how long the orientation questions would take. No technical change, no redesign. Just framing. Users who knew what was ahead approached the process in a more settled emotional state, and the abandonment rate during onboarding dropped meaningfully. Small information, large effect.

#### Designing for the user who actually arrives

The broader principle is that [onboarding should be designed around the actual emotional state](https://weareaffective.com/learning-centre/why-do-some-apps-feel-like-they-were-made-just-for-you) of the incoming user, not an idealised one. A product that assumes its new users are calm, curious, and time-rich will build an onboarding flow that loses the users who are rushed, uncertain, or mildly anxious, which, depending on the product category, could be the majority.

Before finalising your onboarding flow, map the emotional states of users who are most likely to download. If a significant portion are anxious or under time pressure, the flow needs to account for that, not assume it away.

## Give Users Less, Not More

[Nearly 60 per cent of app features are rarely or never used](https://weareaffective.com/learning-centre/5-things-that-make-the-difference-between-so-so-apps-and-stellar-apps-what-your-), according to analysis reported by [Futuristic Bug](https://www.futuristicbug.com/mobile-app-features-for-startups). That figure represents a large amount of development time, a significant budget, and a more complicated product that users have to navigate. The instinct to add more, more features, more content, more options, is understandable but it works against retention.

We built a concierge app for residents moving into a new block of flats, typically high-net-worth individuals arriving at a significant life moment. The natural impulse would be to surface everything the app could offer on day one: recycling locations, emergency procedures, local area guides, building rules. We chose to do the opposite. Rather than presenting the full directory of content on arrival, we drip-fed notifications over time, matched to when users would actually need each piece of information.

Someone who has just moved in is not in a mental state that is receptive to a large volume of information. Some had just bought their first property; others were moving following a separation or a divorce. We sent recycling information a couple of days after move-in, and local area recommendations over the first weekend. The result was a much less overwhelming experience, and users engaged with information they were ready for rather than ignoring everything out of fatigue.

When designing content release, ask when a user is actually ready to receive each piece of information. Timing is part of the experience, not an afterthought.

## When a Native App Is the Wrong Answer

Recommending against building a native app is not a common move for a product consultancy. But it is sometimes the right one. We worked on a surveying app for performance coaches, designed to gather real-time feedback from audiences during live sessions. The original plan called for audience members to download a native app to participate.

We pushed back on that. For what was essentially a simple touchpoint, a question or two during a presentation, asking an audience to find an app, download it, and create an account created a barrier that most people would not clear. The drop-off before anyone answered a single question would have been severe.

#### A QR code instead of a download

Instead, we proposed a different structure. The presenter creates the survey inside the native app, a QR code appears on screen, and audience members scan it to reach a fully branded, mobile-responsive web page. No download, no account, no friction. The experience looked and felt like a native app, and completion rates were significantly higher because the barrier to entry was almost zero.

| Approach | User effort | Drop-off risk | Best suited for |
| --- | --- | --- | --- |
| Native app download | High | High | Repeat, engaged users |
| QR code to web page | Low | Low | One-off or infrequent touchpoints |

The question to ask before committing to a native app is whether the use case genuinely warrants the barrier of a download. For regular, habitual use, a native app is worth the installation. For occasional or passive interactions, that barrier costs more users than it is worth.

## Keeping Users After the Honeymoon Period

The first week of a user's relationship with an app is unlike any week that follows. There is novelty, motivation, and a reason to explore. After that, the product has to hold a user's attention through usefulness rather than relying on curiosity. According to [Kurve](https://kurve.co.uk/blog/app-downloads-statistics), 71 per cent of app users churn within three months of downloading. The products that survive that window do so because they have built genuine habits, not just initial interest.

[Rewarding behaviour rather than just results](https://weareaffective.com/learning-centre/why-your-best-users-are-often-your-worst-source-of-product-direction) is one of the more reliable ways to support habit formation. Results-based achievements, reaching a weight target, finishing a course, hitting a savings goal, have their place, but they only trigger at completion. Behavioural recognition rewards smaller, consistent actions: a daily check-in, a second session in a week, a streak maintained. These are the moments where the habit actually forms, and they are worth acknowledging.

#### Notifications that serve the user

Push notifications sit at the intersection of retention and irritation. A notification that arrives at the right moment with genuinely relevant information can bring a lapsed user back. The same message sent too often, or at the wrong time, becomes a reason to turn off notifications entirely or delete the app. Every notification decision should be evaluated against whether it serves the user at that moment, not whether it serves a re-engagement target.

## Measuring What Matters: Retention Metrics Over Vanity Numbers

[Session length, daily active users, and monthly active user counts](https://weareaffective.com/learning-centre/how-to-read-a-user-session-recording-for-emotional-signal-rather-than-task-compl) look impressive in a product review. They are easy to present, easy to trend upward with the right acquisition spend, and they tell very little about whether the product is actually working. We treat these as vanity metrics, numbers that can mislead a team into confidence while retention quietly deteriorates underneath.

The metrics that matter are retention rates at specific intervals: day one, day three, day seven, and day thirty. These tell you whether users found value quickly enough to come back, and whether that value held over time. A product with climbing download numbers and declining day-seven retention is a product that is spending money to acquire users it is then losing. That is expensive churn.

#### What to track instead

1. Day-one retention: the percentage of users who return the day after first use
2. Day-three retention: where the largest natural drop typically occurs
3. Day-seven retention: a reliable early signal of whether a habit is forming
4. Day-thirty retention: the clearest indicator of long-term product value

The instinct to reach for daily active user counts is understandable, particularly when those numbers are moving in the right direction. But a product that grows downloads without improving retention is working harder and harder to stand still.

## Building Revenue Models Around User Behaviour

Revenue models fail when they are built around what a business wants users to do rather than what users actually do. [A paywall placed before a user has experienced any value](https://weareaffective.com/learning-centre/why-product-owners-should-write-the-users-second-session-before-the-first-one) will convert poorly, not because the price is wrong but because the user has no reason yet to pay. A subscription prompted at the moment a user has just done something satisfying, by contrast, arrives at the right emotional moment.

The connection between retention and revenue is direct: increasing retention by even a small margin can drive disproportionately large profit increases, because the cost of serving an existing customer is far lower than acquiring a new one. That figure reflects the compounding effect of keeping users who already understand and value the product, rather than continuously spending to replace those who leave.

#### Matching the revenue moment to the user journey

Users of branded apps tend to make 33 per cent more purchases compared to non-users, according to [Narang and Shankar, 2019](https://link.springer.com/article/10.1057/s41270-024-00356-5#ref-CR108). That premium comes from familiarity and trust built over time, and it only accumulates if users stay long enough to build it. A revenue model that pressures users before that trust exists trades long-term value for short-term conversion, and almost always gets the worst of both.

The practical approach is to map the moments in the user journey where the product has delivered clear value, and to place revenue prompts there. Not at the start of onboarding, not on the third session of a free trial, but at a moment where the user has already felt what the product can do.

## Conclusion

Building an app that makes money is a narrower problem than it first appears. It is about whether users find value quickly enough to stay, and whether the product earns enough trust over time to generate revenue from people who want to keep using it.

The decisions that shape that outcome are made early. The store listing determines who arrives with the right expectations. The first three seconds determine whether those users stay past the opening screen. Onboarding determines whether they reach value before they lose patience. And retention strategy determines whether any of that investment compounds into something financially worthwhile.

What we have seen across fitness, property, professional services, and several other sectors is that the gap between a product that grows and one that stalls is rarely dramatic. It is often a single poorly timed prompt, a notification strategy that erodes goodwill, or an onboarding flow designed for the wrong user. These are fixable problems, and fixing them tends to move the numbers more than any new feature would.

If you are building something and want to think through the decisions that will actually determine whether it makes money, [let's talk about your app](https://weareaffective.com/get-started).

## Frequently Asked Questions

Why do most apps fail to make money even after a successful launch?

Most apps fail not because of missing features but because of poor early decisions about what to include and who the product is actually built for. Teams tend to design for an idealised, patient user rather than the real one who makes a judgement within seconds of opening the app.

What is the three-day drop and why does it matter commercially?

The three-day drop refers to the point at which, on average, 77 per cent of apps have already lost their daily active users. This matters commercially because revenue follows retention, so if users are not staying past day three, no amount of acquisition spend will build a sustainable income.

What retention rate should a business be aiming for on day one?

A day-one retention rate below 50 per cent is considered a warning sign and should be treated as a problem requiring immediate attention. The goal is to push users well past day thirty, especially where paid acquisition is involved and that spend needs to justify itself.

Why is onboarding described as a financial decision rather than a design one?

Onboarding is the moment a user decides whether the app was worth downloading, which means it directly affects retention and, by extension, revenue. Getting it wrong is not just a design flaw, it is a commercial one that compounds over time as more users are acquired and then lost.

Are download numbers a reliable measure of an app's success?

Download numbers are easy to track and satisfying to report, but they can give a misleading picture of how a product is actually performing. An app can show strong download growth while quietly losing the majority of its users within the first week, which is the figure that truly matters.

When might a native app be the wrong choice for a business?

The article flags that a native app is not always the right tool, depending on the problem a business is trying to solve and the behaviour of its users. Choosing native development without properly examining those factors can lead to unnecessary cost and complexity.

How should a revenue model relate to user behaviour?

A revenue model should work with how users naturally behave rather than against it, meaning it needs to be designed alongside the product rather than bolted on afterwards. Models that create friction or feel misaligned with the user experience tend to suppress the engagement that revenue depends on.

What signals should a product team be watching beyond downloads?

Teams should be tracking retention rates at day one, day three, day five, day seven, and day thirty, as these give a far more accurate picture of commercial health than download counts alone. Watching the wrong signals allows serious problems to develop quietly while the team believes the product is performing well.

## Related Articles

[![We Are Affective](https://weareaffective.com/hubfs/we_are_affective_logo_mark.svg)](https://weareaffective.com)

20-22 Wenlock Road  
London, N1 7GU  
United Kingdom

+44 20 4572 8062  
[hello@weareaffective.com](mailto:hello@weareaffective.com)

<https://linkedin.com/company/weareaffective> <https://instagram.com/weareaffective> <https://facebook.com/weareaffective>

Services

[App planning & strategy](https://weareaffective.com/app-planning-strategy) [App design](https://weareaffective.com/app-design-agency) [App UX design](https://weareaffective.com/app-ux-design) [App UI design](https://weareaffective.com/app-ui-design) [App technical architecture](https://weareaffective.com/app-architecture) [Existing app audits](https://weareaffective.com/app-audit)

Legal

[Privacy policy](https://app.termly.io/policy-viewer/policy.html?policyUUID=b8fa9921-7518-4fb5-8ddd-9dc7f5977ed2) [Terms](https://app.termly.io/policy-viewer/policy.html?policyUUID=8b6a6ad5-91bd-4176-a5f7-6d36b0398f70)

Case studies

[TravAI](https://weareaffective.com/case-studies/travai) [Meditech](https://weareaffective.com/case-studies/harley) [WorkingWeight](https://weareaffective.com/case-studies/workingweight) [SkinSync](https://weareaffective.com/case-studies/skinsync) [Three Lochs](https://weareaffective.com/case-studies/three-lochs) [Drift](https://weareaffective.com/case-studies/drift)

About us

[Our Story](https://weareaffective.com/about) [How We Work](https://weareaffective.com/how-we-work)

Guides

[Creating an app](https://weareaffective.com/how-to-create-an-app) [Building an MVP](https://weareaffective.com/building-an-mvp) [Cost and budgeting](https://weareaffective.com/app-development-cost) [App technology](https://weareaffective.com/app-development) [Planning and strategy](https://weareaffective.com/app-planning-strategy) [User research](https://weareaffective.com/app-user-research) [Onboarding design](https://weareaffective.com/app-onboarding-design) [User psychology](https://weareaffective.com/user-psychology-app-design) [Launch and growth](https://weareaffective.com/app-launch-growth)

 Copyright © 2026, weareaffective.com. All rights reserved.