How to Calculate App ROI (Method, Formulas and Worked Example)

Apps are judged badly more often than any other technology investment. Businesses compare total app revenue against the build cost and declare success, when most of that revenue would have arrived through WhatsApp or the website anyway. Others count downloads, which measure curiosity rather than money.

The honest question is narrower and more useful: what does a customer or staff member do differently because the app exists, and what is that difference worth? This guide shows how to answer it — the full cost side, the cohort method for isolating incremental value, the separate calculation for internal staff apps, and the Nigerian conditions that change the arithmetic.

What makes app ROI different

Three features of apps change the calculation compared with a website or a business system.

• The cost continues. Apps require ongoing maintenance to stay compatible with new Android and iOS versions. Maintenance typically runs at 15–25% of the original build cost per year, and it is not optional; an unmaintained app eventually stops working.
• Value depends on installation, not visits. A website reaches anyone with a link. An app reaches only people who chose to install it, kept it installed, and opened it. Active users, not downloads, are the denominator that matters.
• The counterfactual is strong. Most app customers are existing customers. The correct question is not "how much did app users spend" but "how much more did they spend than they would have without the app".

That third point is where the cohort method comes in, and it is what separates a defensible calculation from wishful arithmetic.

Step 1: Total the app's cost over three years

Use a three-year horizon. One year charges the entire build against a fraction of the value.

Indicative 2026 ranges; actual costs vary with scope, vendor and exchange rate. Obtain two or three written quotations on identical scope before relying on any build figure.

The acquisition line deserves emphasis. An app nobody installs returns nothing, and the cost of driving installs — campaigns, incentives, in-store prompts, staff time — belongs in the cost side of the calculation.

Step 2: Choose the right value model

Apps create value in three distinct ways, and mixing the models produces nonsense.

Identify which one you are before you start. A restaurant's ordering app is the first type. A logistics firm's rider app is the second. A marketplace is the third, and it should be assessed as a business rather than as an internal investment.

Step 3: The cohort method for incremental value

This is the core technique. It isolates what the app actually caused.

1. Define the app cohort: customers who installed the app and have used it at least once in the period.
2. Define a comparison cohort: customers of similar profile — similar spend band, location and tenure — who order through WhatsApp, the website or in person.
3. Measure three things for each cohort over the same period: orders per customer, average order value, and gross margin per customer.
4. Calculate the difference. Incremental margin per app user = app cohort margin per customer − comparison cohort margin per customer.
5. Apply a self-selection discount. Your best customers are likeliest to install the app, so part of the gap existed before the app did. A discount of 20–40% on the measured difference is a defensible convention; state the figure you use.
6. Multiply by monthly active users to get monthly incremental value.

Incremental value per month = (Margin per app user − Margin per comparison user) × (1 − self-selection discount) × Monthly active users

A cleaner variant, if your data supports it: compare the same customers before and after they installed, over equal periods, controlling for season. This removes most of the self-selection problem, though it does not remove the effect of a customer who installed precisely because they were about to buy more.

Step 4: Value the operational savings

Customer apps usually save money as well as making it, and these savings are often easier to evidence than revenue uplift.

• Order-handling cost. Compare the staff time to take a WhatsApp order (read, clarify, confirm stock, send account details, check payment, enter into the system) against an app order that arrives complete and paid. Multiply the difference by app orders per month and by loaded hourly cost.
• Payment reconciliation. In-app payment removes manual transfer matching, which is a genuine recurring cost in most Nigerian businesses.
• Support deflection. Order status visible in the app means fewer "where is my order?" messages. Count the reduction against baseline.
• Error reduction. Fewer wrong items, wrong addresses and mis-typed quantities. Value at the cost of a failed delivery or a return.
• Marketplace commission avoided. If the app shifts orders away from a commission-charging marketplace, the avoided commission is a direct, clean saving.

Each of these needs a measured before-and-after figure, not an estimate.

Step 5: Calculate ROI, payback and cost per active user

Produce four numbers together.

Cost per active user is the diagnostic figure. If an app costs ₦6,000,000 a year to run and has 900 monthly active users, it costs about ₦6,700 per active user per year. Set that against incremental margin per user and the answer is usually obvious without any percentage at all.

Finally, run a sensitivity case: benefits down 30%, costs up 20%. If payback still lands inside three years, the case holds.

Example (hypothetical): a pharmacy chain's ordering app

Example (hypothetical): a four-branch pharmacy chain in Port Harcourt builds a customer ordering and refill-reminder app. Figures are illustrative planning numbers, not quotations or client results.

Three-year cost

Value, using the cohort method

• App cohort: gross margin per customer of ₦4,900 per month, driven by refill reminders increasing repeat purchases.
• Comparison cohort: ₦3,400 per month for matched walk-in and WhatsApp customers.
• Raw difference: ₦1,500 per customer per month. After a 30% self-selection discount: ₦1,050.
• Average monthly active users across the three years: 2,200.
• Incremental margin: about ₦2,310,000 per month, or ₦27,720,000 a year — but note this assumes stable active users, so the chain modelled a ramp of 900 in year one, 2,400 in year two and 3,300 in year three, giving roughly ₦83,160,000 across three years at the discounted rate.
• Operational savings: reduced order-handling time and fewer manual transfer confirmations, valued conservatively at ₦4,500,000 across three years.

Result: total value of roughly ₦87,660,000 against ₦19,390,000 of cost. ROI is strongly positive and payback falls inside year one of meaningful adoption.

The honest caveat: this result rests entirely on the ₦1,050 incremental margin figure and on the active-user ramp. Halve either and the picture changes substantially. That is why the chain should verify the cohort gap quarterly rather than calculating once and quoting the number for three years. This is an illustrative scenario, not a client account.

Internal and staff apps need a different calculation

For a rider app, a sales-agent app or a field-inspection app, there is no revenue cohort. Value comes from four measurable lines:

1. Time saved per task, measured before and after, multiplied by frequency and loaded hourly cost, with a 25–50% realism discount.
2. Errors removed, valued at the real cost of a failed delivery, a wrong order or a disputed payment.
3. Capacity gained. If each agent can now handle 30% more visits, value that as avoided hiring or additional revenue, but not both.
4. Data quality. Field data captured at the point of work rather than reconstructed at the end of the day improves planning, billing accuracy and dispute resolution. Value the billing accuracy; note the rest qualitatively.

The cost side is the same, except that install acquisition is replaced by training and device provisioning, which for field staff can be substantial.

What changes when you calculate app ROI in Nigeria

• Install friction is higher. Data costs and limited device storage mean people delete apps they do not use weekly. Build a realistic churn assumption into your active-user forecast rather than assuming installs are permanent.
• App size matters commercially. A large download costs the user money in data, which suppresses installs. A lighter app is an ROI decision, not only an engineering one.
• A web app may be the fairer comparison. Before claiming app ROI, ask what a mobile-optimised web app or progressive web app would have delivered at a fraction of the cost. The correct comparison for ROI is against the next-best alternative, not against doing nothing.
• Dollar-denominated costs. Hosting, store fees, push services and AI features are USD-priced while benefits are in naira. Model at a conservative rate and show sensitivity to a weaker naira.
• Offline behaviour affects realised value. An app that fails during a network drop loses orders and field data. If offline capability was not built, reflect the lost value rather than assuming perfect conditions.
• Payments and trust. In-app payment only delivers reconciliation savings if customers actually use it. If most still pay by transfer, that saving is smaller than forecast.

When the app does not pay back

Some honest situations where the calculation returns a negative answer:

• Low purchase frequency. Apps repay best where customers buy often. A business whose customers buy twice a year rarely justifies a dedicated app.
• Small customer base. Fixed app costs divided by a few hundred users produce an unaffordable cost per active user.
• The website already does the job. If a mobile site handles ordering well, the app's incremental contribution may be close to zero.
• No reason to keep it installed. Without ordering, tracking, loyalty or an account, an app is a brochure with a download step.
• No budget for maintenance. An app funded for the build and not the following three years will decay, and the ROI calculation should assume that.

Concluding that an app does not pay back is a successful use of the method, not a failure of it.

Mistakes that distort app ROI

• Counting all app revenue as new. Most of it moved from another channel.
• Using downloads instead of active users. Downloads measure interest; active users measure value.
• Excluding maintenance. Three years of maintenance can approach half the build cost.
• Ignoring acquisition cost. Installs are not free, whether you pay for ads or staff time.
• Skipping the self-selection discount. Your best customers install first, and they were already your best customers.
• Comparing against nothing. Compare against the realistic alternative, usually a mobile website.
• Calculating once. Recalculate quarterly; cohort gaps and active users both move.
• Charging everything to year one. Use the horizon the asset actually serves.

Conclusion

Calculate app ROI by isolating what the app changed. Build a three-year cost side that includes maintenance, hosting, store fees, notifications and acquisition. Build the value side with the cohort method, discount it for self-selection, add measured operational savings, and quote payback period and cost per active user alongside the percentage. Then run the sensitivity case and recalculate quarterly. Most importantly, compare the app against a good mobile website rather than against doing nothing: that comparison is what most app business cases quietly avoid, and it is the one that matters.

If you are planning an app and want the numbers before the build, Linestech can scope the work, cost the three-year ownership properly, and help you set the baseline measurements that make the return provable afterwards.

Frequently asked questions

How many active users does an app need to be worth it?

There is no fixed threshold, because it depends on incremental margin per user and on your fixed costs. Work it backwards: divide your total annual app cost by the incremental margin per active user per year, and the result is the number of active users you need to break even. If that number exceeds a realistic share of your customer base, the app is unlikely to pay back.

Should I count app revenue that would have come through WhatsApp anyway?

No. Channel-shifted revenue is not incremental revenue, although the cost saving from handling it more cheaply is a genuine benefit. Count the operational saving on shifted orders and count only the additional purchase frequency or order value as revenue uplift. This distinction is what makes the calculation credible.

How do I measure ROI on an app that is still being built?

You forecast it, label it a forecast, and record the baselines you will need later: current order frequency per customer, current order-handling time, current support message volume and current error rates. The forecast's main value is that it defines the success measures before anyone has an incentive to redefine them.

What is a reasonable payback period for a business app?

For most Nigerian SMEs, an app that has not paid back within two to three years is hard to defend, because the maintenance obligation continues indefinitely and platform requirements keep changing. Product apps that are the business itself are judged differently, on growth and unit economics rather than on payback against an internal alternative.

Does app store commission affect the calculation?

It does where digital goods or subscriptions are sold through the stores, since platform commission reduces net revenue. Physical goods and services paid through a Nigerian payment gateway are generally handled differently. Confirm the current rules in Apple and Google's developer documentation, because platform policies change and they materially affect margin.

How do I value an app that mainly improves customer experience?

Trace experience to behaviour. Better experience should show up as higher repeat purchase rate, lower churn, fewer complaints or higher average order value, all of which are measurable against the comparison cohort. Where you cannot trace it to behaviour, record it as a qualitative benefit rather than assigning an invented number.

Should the cost of a failed app be written off entirely?

Not necessarily. Design work, backend systems, integrations and the data model often survive into a replacement, and the operational learning has value. Record the recoverable elements explicitly when assessing the loss, then be honest about the rest. The more useful exercise is identifying why it failed — usually adoption, not technology — before committing to a rebuild.

Sources and further reading

Figures, platform rules and regulations change. These are the primary references behind this article and the places to check before you act on it.

• Apple Developer Program
• Cloudflare Learning Center
• Nielsen Norman Group UX research