Estimate your mobile app ROI
What your existing customers could add, what the app costs to run, and the month it pays for itself.
Your store
Use the example values or enter your store's figures. All amounts in USD, covering the last twelve months.
These two set the size of your customer base, not the size of the return. They turn your revenue into a customer count, so you can check the adoption percentage below against install numbers you recognise. The arithmetic then cancels them out exactly: your app cohort's share of revenue is fixed by how many customers adopt and by how much more they already spend, whatever basket sits behind it. Change either one and the count moves; the money does not. The count is an estimate either way, because a returning-customer rate fixes how many people come back, never how often.
Out of every $100 you sell, how much is left after what the product cost you, shipping it, payment fees and returns? This is the single biggest lever on the answer, so it is the one worth checking against your own numbers. Picking a category above fills in a starting figure.
Who ends up on the app
A share of people, not of revenue. Claiming a share of revenue would assume the answer. We publish no range here: adoption depends on how hard you push it, not on what you sell. Zero is a legitimate downside case.
What changes for them
The two lifts the app is bought for. The shaded stretch on each track is an illustrative range, not a measured benchmark.
Illustrative range: +5% to +15%
How much more an app order is worth than the same customer's web order.
Illustrative range: +10% to +30%
Where an app usually earns its money, and usually the larger of the two lifts.
Both lifts are a change across ALL of an adopter's spending, not a comparison between app orders and web orders. They apply only to the app cohort, never to your whole store. Within that cohort they apply to all of their spend, which is slightly generous: some of their orders will still happen on desktop.
What it costs, growth or no growth
Apple's Developer Program ($99 a year, billed in months 1, 13 and 25) and Google Play's one-off $25 registration fee are added automatically. If you already pay them, the result is understated by that much.
Illustrative range: 1.4x to 1.8x
Installs skew towards your best customers, so the cohort's baseline sits above your store average. Note which way this moves the answer: raising it RAISES the estimate, in proportion. It is a baseline correction, not a conservative one.
Illustrative range: 40% to 60%
A loyal customer placing their usual order in the app instead of the website has not made you a penny. This throws away the share that was coming anyway. Zero is a legitimate downside case: it says the app changed nothing.
From their spending to your return
- What your app users already spend2.2k customers (estimated), before the app exists. Excluded from the total below.$384,000
- Bigger baskets10% more per order+$38,400
- More often20% more orders a year+$76,800
- Both at oncebigger baskets on the extra orders, which belongs to neither lever alone+$7,680
- Would have happened anyway50% of the lift, stripped out-$61,440
2.05% of everything you sell, reached once adoption settles at month 12. Revenue, not profit: 25% of it survives to the figures above.
What the result assumed
- Annual online revenue$3,000,000 USDYour figure
- Average order value$75 USDYour figure
- Orders per customer a year1.4 (estimated from your returning-customer rate)Derived
- Customers on the app by month 128%Your figure
- Left on each sale after variable costs25%Your figure
- Bigger baskets10%Illustrative
- More orders a year20%Illustrative
- How much more adopters already spend1.6xIllustrative
- Share of the lift the app caused50%Illustrative
- Build and launch$0 onceYour figure
- Running cost$649 a monthYour figure
- Store fees$99 a year (Apple, billed in months 1, 13 and 25) and $25 once (Google)Published price
- Adoption rampStraight line from zero to the figure above across 12 monthsAssumed
- Horizon36 months. Nothing after month 36 counts.Published price
- Model version2026.09-contributionPublished price
What is left out
Anything after month 36. Support-cost savings. New customers, anywhere. Your stack, catalogue size and launch timeline. The $384,000 your app users already spend is excluded on purpose, so do not add it to the incremental figure.
Month by month
The exact values behind the chart. Cumulative starts at -$25, the build cost plus Google's registration fee, owed before the app earns anything.
| Month | Revenue | After margin | Cost | Net | Cumulative |
|---|---|---|---|---|---|
| 1 | $427 | $107 | $748 | -$641 | -$666 |
| 2 | $853 | $213 | $649 | -$436 | -$1,102 |
| 3 | $1,280 | $320 | $649 | -$329 | -$1,431 |
| 4 | $1,707 | $427 | $649 | -$222 | -$1,653 |
| 5 | $2,133 | $533 | $649 | -$116 | -$1,769 |
| 6 | $2,560 | $640 | $649 | -$9 | -$1,778 |
| 7 | $2,987 | $747 | $649 | $98 | -$1,680 |
| 8 | $3,413 | $853 | $649 | $204 | -$1,476 |
| 9 | $3,840 | $960 | $649 | $311 | -$1,165 |
| 10 | $4,267 | $1,067 | $649 | $418 | -$747 |
| 11 | $4,693 | $1,173 | $649 | $524 | -$223 |
| 12 | $5,120 | $1,280 | $649 | $631 | $408 |
| 13 | $5,120 | $1,280 | $748 | $532 | $940 |
| 14 | $5,120 | $1,280 | $649 | $631 | $1,571 |
| 15 | $5,120 | $1,280 | $649 | $631 | $2,202 |
| 16 | $5,120 | $1,280 | $649 | $631 | $2,833 |
| 17 | $5,120 | $1,280 | $649 | $631 | $3,464 |
| 18 | $5,120 | $1,280 | $649 | $631 | $4,095 |
| 19 | $5,120 | $1,280 | $649 | $631 | $4,726 |
| 20 | $5,120 | $1,280 | $649 | $631 | $5,357 |
| 21 | $5,120 | $1,280 | $649 | $631 | $5,988 |
| 22 | $5,120 | $1,280 | $649 | $631 | $6,619 |
| 23 | $5,120 | $1,280 | $649 | $631 | $7,250 |
| 24 | $5,120 | $1,280 | $649 | $631 | $7,881 |
| 25 | $5,120 | $1,280 | $748 | $532 | $8,413 |
| 26 | $5,120 | $1,280 | $649 | $631 | $9,044 |
| 27 | $5,120 | $1,280 | $649 | $631 | $9,675 |
| 28 | $5,120 | $1,280 | $649 | $631 | $10,306 |
| 29 | $5,120 | $1,280 | $649 | $631 | $10,937 |
| 30 | $5,120 | $1,280 | $649 | $631 | $11,568 |
| 31 | $5,120 | $1,280 | $649 | $631 | $12,199 |
| 32 | $5,120 | $1,280 | $649 | $631 | $12,830 |
| 33 | $5,120 | $1,280 | $649 | $631 | $13,461 |
| 34 | $5,120 | $1,280 | $649 | $631 | $14,092 |
| 35 | $5,120 | $1,280 | $649 | $631 | $14,723 |
| 36 | $5,120 | $1,280 | $649 | $631 | $15,354 |
01
How the estimate works
Six decisions sit between your store's figures and the number at the top of this page. Each one lowers the result a simpler model would print, and each one is yours to change.
The money is in retention
Almost nobody discovers a brand through its app. What an app changes is the behaviour of people who already buy from you. No new customers appear anywhere in this model.
Adoption is a share of people
Ask for a share of revenue and you have already assumed the answer. Here you set the share of your customers who end up on the app, which you can check against your install numbers.
Installers are your best customers
App installs are not a random sample. The people who bother are the ones who already buy the most, so their baseline sits far above your store average.
Only the caused part counts
Your most loyal customers were going to order again. If they place that order in the app instead of the website, nothing improved. The model strips out the share you tell it was coming anyway.
Revenue ramps
No app reaches steady adoption in month one. The model assumes a straight climb across the first year, so year one collects about 6.5 times the monthly run rate rather than twelve.
Margin comes off before anything counts
Extra revenue is not extra profit. Only what survives the product cost, the shipping, the payment fees and the returns reaches the result, which is why that one field moves the answer more than any other.
0
new customers assumed, anywhere in the model
6.5x
what year one collects, against a flat model’s 12x
50%
of the assumed lift discarded by default as self-selection
02
Why we assume a lift at all
The calculator is cautious about how large the lift is. It is not cautious about whether one exists. These are published, dated results from named Shopify brands running Napps.
Read them as what they are: app customers compared with website customers at the same brand. App users choose themselves, so part of every gap below is people who already spent more, before any app existed. That is exactly what the two cohort and attribution settings in the calculator take back out, which is why none of these figures is loaded into it as a default.
Average order value
Farma2Go, Shopify Plus, Spain. App orders against storefront orders, published July 2026. Farma2Go case study
Spend per customer
Farma2Go again, over the same period: app customers against storefront customers. Farma2Go case study
Revenue per customer
Zippy Kids Store, Shopify Plus, Portugal. App customers against website customers, published July 2026. Zippy Kids Store case study
03
Questions the numbers raise
From the customers you already have buying more often and spending more each time. That is the whole mechanism. A slice of your base installs the app, and because it sits on their home screen and remembers their card, the gap between their orders shortens and their baskets get bigger. You can add zero new customers and still see a real return. The calculator models exactly that and nothing else, which is why new-customer acquisition never appears as an input.
No. They apply only to the customers who adopt the app, which at the default settings is a fraction of your revenue, not all of it. Non-adopters do not change their behaviour because an app exists. One simplification is worth knowing: within the adopting cohort the lifts are applied to all of that cohort’s spend, as though they never buy on desktop again. In reality some of their orders still happen on the website, so the true lift is a little smaller. The causal-share haircut absorbs part of that, and it is one reason we keep that setting conservative.
Because a share of revenue smuggles in the answer. If you tell a model that 10% of revenue runs through the app, you have already assumed the outcome you were trying to calculate. A share of people is a fact you can check against your install numbers, and everything downstream is then derived rather than asserted.
They are the two assumptions that move the answer most, so we expose them rather than bury them. The first says your app cohort was already spending more than your average customer, because installs are never a random sample: the people who bother are the ones who already love you. Note which way it moves the result, because it is easy to mistake for a conservatism: raising it RAISES the estimate, in proportion. The second throws away the share of the extra spend that was coming anyway, since a loyal customer placing their usual order in the app instead of the website has not made you a penny. Both defaults are illustrative starting points rather than measured figures, and both are meant to be overwritten if you have run a holdout or geo test.
What remains of every $100 you sell after what the product cost you, after shipping it, after payment fees and after returns. It is not gross margin, which counts only the cost of the goods and ignores the cost of getting the order to someone. The difference is not cosmetic: run the default scenario on gross margin and it reads as a small profit in year one; run it on what is genuinely left and it is several thousand dollars down, with payback most of a year later. That one number multiplies the only figure that counts, so this calculator asks for the honest version, and asks for it once rather than offering you a choice of definitions. Picking a category loads a starting figure, but this is the number most worth replacing with your own.
No, and that is a limitation we would rather state than hide. Nothing in the model links your promotion budget to the adoption rate you set, so the two are independent inputs. You can assume a lot of adoption on very little spend and the model will not stop you. It will warn you, because adoption near the top of the range takes sustained push, CRM and merchandising behind it.
Lifetime-value effects beyond the three-year horizon, which usually favour the app and which we would rather omit than estimate. Support-cost savings, for the same reason. And anything specific to your stack, catalogue size or launch timeline. This is a scenario estimate: not a forecast, and not a floor. Actual results may be higher or lower.
They are illustrative starting points, not measured benchmarks, and the tool labels them that way. We have no published dataset behind the basket lift, the frequency lift, the adopter-quality multiplier or the causal share, so we do not claim one. They exist so the form is never blank, and so the downside and upside cases have somewhere defensible to move between. Every one of them is meant to be overwritten with a number you have measured. The customer results further down this page are real, named and dated, but they are evidence that a lift exists, not evidence of how large it would be in your store.
Bring us the inputs you disagree with
Adoption, the two attribution settings and what is really left on each sale are judgement calls, and they are the ones worth arguing about. Forty-five minutes with your actual catalogue, stack and margins gets you a version of this you can take to a board.
Trusted by leading Shopify brands
Calendar not loading? Open the booking page directly .