AI app unit economics are easy to misunderstand when a product has thousands of installs, strong store ratings, hundreds of subscribers, and meaningful-looking revenue. A candid r/SaaS post from a solo developer in Germany is a useful corrective: the app reached roughly €22,000 in gross revenue, yet the founder calculated an all-in loss of about €5,800 before paying themselves for their time.

The app is a photo-based calorie tracker that uses AI to estimate calories and macros. It is the kind of consumer product that looks ideal for the current app economy: a clear use case, a visually compelling AI feature, subscription monetization, and a repeatable daily habit. But the reported numbers show the difficult arithmetic beneath that story.

According to the founder’s post, the app had about 13,300 users who actually opened it, 678 active subscriptions, ratings around 4.7 on Google Play and 4.65 on the App Store, and roughly $2,200 in monthly recurring revenue. Those are not trivial validation signals. Yet after platform fees and VAT, reported proceeds were about €14,300, while advertising, cloud inference, coding tools, subscriptions infrastructure, and developer accounts pushed total outgoings to roughly €20,100.

The lesson is not that AI subscription apps cannot work. It is that founders need to treat cash collected, customer acquisition cost, cost to serve, and retention as one connected system—not four separate dashboards that each look reassuring in isolation.

The numbers behind the “successful” app that was still unprofitable

The original r/SaaS post is valuable precisely because it does not present revenue as the ending of the story. The founder shared a basic all-time operating ledger rather than a screenshot of monthly revenue alone.

Here is the reported picture, rounded for clarity:

About 13,300 activated installs: roughly 8,975 on Android and 4,322 on iOS.
Around 678 active subscriptions.
Approximately €22,000 in gross revenue.
Approximately €14,300 received after app-store deductions and VAT.
About €7,514 spent on Google Ads.
About €5,356 spent on Apple Search Ads.
Around €3,900 in Google Cloud costs, largely model calls and search grounding.
About €3,000 on Cursor and Claude Code over the period.
About €360 for RevenueCat and developer-account costs.
A reported overall loss near €5,800, excluding the developer’s own labor.

The arithmetic makes the point more vividly than any generic startup warning. Gross revenue was not spendable revenue. Paid installs did not equal profitable customers. And the AI feature was not a one-time development expense; it created a recurring marginal cost whenever someone logged food.

This is especially important for founders building consumer AI products. Traditional mobile subscriptions already have fragile economics because trial conversion, refunds, store fees, payment timing, and churn distort the revenue number. Add image analysis, model calls, web search, or other paid AI services, and every active free user can become an ongoing variable expense.

The founder’s reported loss also contains two different categories that should not be casually mixed:

Direct business costs, such as ad spend, store deductions, subscription tooling, and production AI infrastructure.
Founder productivity costs, such as AI coding subscriptions.

Both matter for cash flow. But they answer different questions. The first tells you whether the product can eventually earn contribution profit at scale. The second tells you how much capital or personal cash the founder used to build and operate it. A company can have viable customer-level economics while still burning money because its tooling, experimentation, or team costs are too high. Conversely, it can have low overhead while losing money on every incremental customer.

In this case, the founder’s own update suggests the app may become modestly positive after paid acquisition is turned off: recent post-fee revenue was reportedly €1,400 to €1,800 per month, while cloud costs had climbed to roughly €800 to €1,200. That is not a large margin, but it changes the question from “Does the app work?” to “Can organic demand and retention sustain it without paid traffic?”

Why gross revenue is the most dangerous number in mobile subscriptions

Gross revenue is useful for measuring customer willingness to pay. It is poor shorthand for profitability.

For a mobile subscription business, money can disappear before it reaches the company bank account through platform commissions, VAT or sales tax handling, refunds, chargebacks, currency conversion, and subscription-management expenses. Apple’s Small Business Program can reduce commission to 15% for qualifying developers with up to $1 million in prior-year proceeds, while Apple also notes that standard digital-goods commission is generally 30% outside qualifying arrangements. (developer.apple.com) Google Play likewise states that most developers subject to a service fee are eligible for 15% or less through its available programs, although exact fees and billing choices vary by market and program. (support.google.com)

That means a €39.99 annual subscription is not automatically €39.99 of usable revenue. A founder needs to know the actual expected proceeds for each product, country, platform, and billing path.

The four revenue figures every app should report

A clean mobile subscription dashboard should separate at least four layers:

Customer billings: what users were charged before deductions.
Net store proceeds: what Apple or Google remits after its fee, tax treatment, refunds, and adjustments.
Net revenue after service costs: proceeds minus the cost to provide the core service, including AI inference, storage, moderation, and support.
Contribution profit after acquisition: net revenue after the marketing cost required to acquire that user.

The post’s €22,000-to-€14,300 shift is why this separation matters. If a founder sees only the first figure, the product appears to have cleared an important early milestone. If they see the third and fourth figures, they can identify the actual bottleneck.

For this app, the bottleneck was not simply “low revenue.” It was a stacked cost structure:

Store and tax deductions reduced gross customer payments.
Paid acquisition consumed more cash than early subscriber revenue recovered.
AI usage costs increased as product engagement increased.
Development tools added meaningful overhead during the early build-and-iterate phase.

That is not an argument against subscriptions. It is an argument for building financial reporting around what reaches the bank account and what each additional customer costs to serve.

A useful internal metric is net contribution margin per activated user:

Net store proceeds per activated user – variable AI/service cost per activated user – allocated acquisition cost per activated user

For a freemium AI app, calculate this separately for free users, trial users, monthly subscribers, annual subscribers, and reactivated subscribers. An average across everyone can hide the fact that one cohort is funding another.

The real advertising problem was optimization, not just ad spend

The most revealing detail in the founder’s account is the mismatch between advertising-platform reporting and subscription reality.

Google Ads appeared to show a cost per acquisition around €1. But after the founder matched click IDs to RevenueCat data, the reported effective cost per paying user was closer to €22. In other words, the campaign was successfully buying an upstream behavior—an app open or similar engagement event—rather than the business outcome that mattered: a paying subscriber who produced enough net revenue to cover their acquisition and service costs.

This is a common growth failure, especially in mobile apps. The dashboard can be technically accurate and still strategically misleading.

A cheap event is not a cheap customer

An ad platform can optimize toward almost any measurable event:

Impression
Click
Store-page visit
Install
First open
Account creation
Onboarding completion
Trial start
First purchase
Renewal
Predicted lifetime value

The cheapest event is usually not the most valuable one. Optimizing for installs may attract users who download on impulse and never open the app. Optimizing for opens can attract curious people who complete a superficial action but never reach the paywall. Even optimizing for trial starts can be misleading if trials are easy to claim and users cancel before payment.

The right optimization event depends on volume. A new app may not have enough purchase events for a platform to learn efficiently, so founders sometimes begin with a proxy event. But a proxy needs to be tightly connected to monetization.

For a calorie-tracking app, a stronger early-funnel proxy might be:

User installs and opens the app.
User completes onboarding.
User scans or logs their first meal.
User logs a second meal on a different day.
User views the paywall after receiving a meaningful result.
User starts a trial or purchases.

That sequence does not guarantee profitability. It does, however, distinguish someone who merely opened an AI camera experience from someone who has started building a tracking habit.

The founder’s experience with Apple Search Ads was also sobering. The post says Apple Search Ads did not pay back in any month, including a period in which nearly €2,000 spent brought back roughly 40% of that amount. Search ads can capture high-intent users, but high intent does not override bad unit economics. If a paid subscriber’s early proceeds are smaller than their acquisition cost plus AI cost, the campaign is funding learning rather than buying profitable growth.

AI app unit economics require a cost-to-serve model

In a normal habit tracker, another free user may add negligible incremental cost. In an AI photo-analysis product, a new active user can create billable requests from day one.

That changes product strategy. The founder reported cloud expenses of roughly €800 to €1,200 per month at the time of writing, with more than 80% associated with model calls and Google Search grounding. The app reportedly uses web search to improve calorie estimates for known branded foods or restaurant items—useful functionality, but another metered step in the request path.

Google Cloud’s generative AI pricing is usage-based, and model or agent-platform costs vary based on the selected services and the amount of inference consumed. That makes monitoring request-level cost a product requirement, not merely a finance task. (cloud.google.com)

Track cost per successful outcome, not cost per token alone

Token pricing is important, but it is too low-level to guide a product business by itself. The more actionable measure is the cost of a useful customer outcome.

For this category, that might mean tracking:

Cost per completed meal analysis.
Cost per analysis a user saves to their diary.
Cost per active free user per week.
Cost per active subscriber per month.
Cost per trial user who later converts.
Cost per retained subscriber who reaches a second billing event.

An image pipeline might include image upload, vision inference, structured nutrition extraction, web grounding, retries, validation, storage, analytics, and notification services. Each step can look inexpensive alone. At consumer volume, the combined path becomes the actual cost of goods sold.

Founders should also calculate the p95 cost per request, not only the average. A small number of expensive calls—large images, lengthy conversations, repeat scans, failed parses, or multi-step agent loops—can quietly produce a disproportionate share of the bill.

Cost controls that preserve user value

The community response to the post focused heavily on model costs. Some commenters suggested cheaper models, local open-weight models, routing, and regular model evaluation. Those are sensible directions, but the goal should not be “use the cheapest model.” The goal is to protect the user-visible result while lowering cost per retained user.

Practical levers include:

Model routing: Send simple branded-food lookups or clear package labels to a cheaper model or deterministic database lookup; reserve the best multimodal model for ambiguous meals.
Confidence thresholds: Ask for clarification, request a second image, or surface a range when confidence is low instead of launching repeated expensive calls automatically.
Caching: Cache common restaurant products, branded foods, and repeated user meals when licensing, freshness, and privacy requirements allow it.
Image preprocessing: Resize images, strip unnecessary metadata, and control image quality before costly vision requests.
Feature gating: Give free users enough value to understand the product, but set limits on expensive scans, history analysis, or deep nutritional breakdowns.
Budget alerts: Set daily and monthly caps by feature, model, country, acquisition channel, and user cohort.
Evaluation harnesses: Test lower-cost alternatives against a representative benchmark set before changing the live model.

The right answer may still be a premium model. If the expensive model materially improves user trust, logging frequency, paid conversion, or retention, its extra cost can be justified. But that case should be proven with cohort data, not assumed because the output “feels” better.

Pricing tests exposed a familiar subscription trade-off

The founder tested prices from €2.99 to €5.99 per month before raising pricing to €7.99 monthly and €39.99 annually. The reported result was nuanced: the annual plan held up, the monthly plan weakened sharply, but revenue per paywall view rose—so the higher pricing stayed.

That is a better decision framework than optimizing for conversion rate alone.

A lower price often lifts the percentage of users who pay, particularly in the first billing cycle. But if the product has meaningful serving costs, low pricing can attract the wrong form of demand: users who convert but do not leave enough gross margin to fund support, platform deductions, ongoing model calls, and acquisition.

Price against the cost of the habit, not the novelty of AI

A photo calorie tracker has to earn retention through repeated behavior. A user might pay once because AI meal scanning looks impressive; they will stay only if it makes food logging meaningfully easier, more consistent, or more motivating than alternatives.

That makes annual pricing strategically useful. It supplies cash upfront, reduces payment friction, and gives the company more time to help users build a routine. However, annual billing is not a shortcut around product-market fit. It also brings a liability: a business that spends all annual cash immediately may have to support that user for the next year without additional payment.

The key pricing measures are therefore not just paywall conversion and first-payment revenue. Founders should track:

Revenue per paywall view.
Trial-to-paid conversion by plan.
Refund and cancellation rates by plan.
Net proceeds by country and store.
AI cost per subscriber by plan.
Second-payment rate for monthly subscribers.
Renewal rate for annual subscribers.
Contribution margin by acquisition channel.

Subscription benchmarks can be helpful for setting questions, but they should not replace a product’s own cohort data. RevenueCat’s 2025 subscription-app report specifically highlights how AI is reshaping subscription businesses and how monetization and retention remain central to their performance. (revenuecat.com) The practical takeaway is simple: high initial conversion is welcome, but retention determines whether acquisition spending can ever be recovered.

LTV is not an excuse to ignore payback

One commenter correctly noted that ad efficiency cannot be assessed entirely from first-payment revenue without considering lifetime value (LTV). The founder’s response was equally correct: with a product only around six months old and a large annual-plan component, true LTV was not yet known.

This is a tension every early subscription app faces. You need LTV to evaluate customer acquisition cost, but you need time and cohorts to estimate LTV responsibly.

The mistake is resolving that uncertainty by assuming a generous LTV. The safer approach is to use scenarios.

Build a conservative LTV range

Instead of one lifetime value figure, calculate three:

Downside LTV: assumes weak renewal and higher-than-expected refunds or churn.
Base-case LTV: based on observed cohort retention and realistic renewal assumptions.
Upside LTV: assumes product improvements and stronger retention, but is not used to authorize baseline ad spend.

Then compare all three with fully loaded acquisition cost and cost to serve.

For example, if a yearly subscriber pays €39.99, the company should not call that €39.99 LTV. It should subtract expected platform and tax deductions, refunds, any affiliate or advertising cost, and estimated AI usage across the service period. Only then should it consider probable renewal value.

A €22 cost per payer may be acceptable if net contribution profit from that customer reliably exceeds €22 within a defined payback window. It is dangerous if it takes a hypothetical future renewal to become viable.

For early-stage bootstrapped apps, a practical rule is to separate two budgets:

Learning budget: money deliberately spent to gather user feedback, validate positioning, improve onboarding, and collect enough conversion data to make better decisions.
Growth budget: money spent only when a channel has evidence that it can recover customer acquisition cost within an acceptable period.

The founder’s post is unusually clear that paid traffic served both purposes. The ads did not pay back directly, but they delivered users, feedback, reviews, and bug reports that improved the app. That can be rational—provided it is labeled as research and product-development spend rather than profitable scaling.

Why turning off ads may be the right next experiment

The founder has now turned off ads to see whether organic installs hold up. That is not necessarily “slow death.” It is a clean experiment.

When paid spend stops, several outcomes are possible:

Installs fall sharply and subscription revenue declines in parallel.
Installs fall, but conversion and retention improve because low-intent traffic disappears.
Organic installs remain relatively stable because reviews, rankings, referrals, and accumulated brand demand carry more weight than expected.
Installs decline at first but recover after product improvements, app-store optimization, or content efforts replace part of paid acquisition.

The experiment only becomes useful if cohorts are measured. The founder should compare paid and organic users by activation, number of meals logged, paywall view rate, trial rate, paid conversion, refund rate, AI cost, and retention—not merely by installs.

A 90-day post-paid-acquisition dashboard

For the next three months, an AI subscription app in this position should watch:

Organic activated installs, split by iOS and Android.
First-value completion, such as the first successful food scan and first saved meal.
Weekly meal-logging frequency among free users, trials, and subscribers.
Paywall-view-to-purchase conversion by platform and plan.
Net proceeds per new subscriber, rather than customer billings.
Variable AI cost per active user and per subscriber.
Cohort retention, especially monthly second payments and annual cancellation/refund behavior.
Store review velocity and qualitative support themes.
Contribution margin by acquisition source.
Cash runway, including annual billing obligations and fixed tools.

If organic traffic fades, that does not mean paid acquisition must return unchanged. It may mean the product needs a different distribution engine: app-store listing experiments, nutrition content, partnerships with coaches, short-form demonstrations, referral loops, public progress features, or a less expensive free experience that creates word of mouth.

For the operational side, accurate event capture is essential. Teams integrating subscription state, transactional messaging, and lifecycle nudges should make sure their instrumentation is grounded in reliable server-side events and documented workflows rather than ad-platform reporting alone; an email API setup guide can help when building the notification layer around trials, renewals, payment failures, and reactivation campaigns.

Community reaction: praise for transparency, pressure on costs

The r/SaaS community largely treated the post as a rare example of useful transparency. Several commenters praised the founder for sharing a real operating picture instead of presenting revenue as proof that everything was working. That reaction matters because public startup discussions often reward top-line numbers, while candid discussions of tax, platform deductions, cost of inference, and failed acquisition tests are much more useful to builders.

The comments also surfaced three substantive critiques.

First, several people questioned the cloud and development-tool spend. Suggestions ranged from testing lower-cost models to routing requests through alternative providers or operating local models. The broad point was sound: in AI products, model choice should be reevaluated regularly because the trade-off between quality, latency, reliability, and cost changes quickly.

Second, an experienced PPC commenter argued that Google Ads might benefit from more professional account management. That is plausible, but founders should be careful not to interpret “hire an agency” as an automatic fix. Better campaign structure cannot overcome a product whose net revenue per customer is too small. Paid-growth expertise is most useful after the company has clean event data, a viable activation path, a credible LTV range, and enough purchase volume to optimize toward meaningful outcomes.

Third, commenters debated whether the app’s calorie estimates could be exact enough, especially because meals vary in preparation and portion size. The founder said users had not complained and described using web search for known branded foods and restaurant items. This exchange points to an important product truth: many health-tracking users may value consistency and convenience more than laboratory-level precision. But that does not eliminate the need for careful positioning. The product should make clear that visual estimates can be approximate and should not present itself as medical advice.

What founders should copy—and what they should not

The strongest part of this founder’s approach was not the ad spend or model stack. It was the willingness to reconcile data across systems and admit what the reconciliation showed.

Worth copying

Compare ad-platform data with revenue data. Tie click IDs or campaign metadata to trials, purchases, refunds, and renewals where possible.
Track net proceeds. Build dashboards from money actually received, not just store billings.
Count inference as cost of goods sold. AI spend belongs in unit economics from the beginning.
Use paid traffic deliberately for learning. If it is not profitable, label it validation spend and cap it.
Test price using revenue quality. Look at revenue per paywall view and contribution margin, not conversion alone.
Listen to qualitative feedback. Bug reports, support messages, and reviews can reveal activation blockers that dashboard data misses.

Not worth copying blindly

Scaling campaigns on install or open metrics. Those events can look cheap while producing expensive payers.
Assuming annual plans solve cash flow permanently. They help upfront cash but create a future support obligation.
Treating a high store rating as proof of sustainable growth. Ratings validate user satisfaction; they do not directly prove margin or retention.
Leaving free AI usage unlimited by default. A viral free feature can turn growth into an infrastructure bill.
Using one blended CAC number. Channel, platform, country, creative, plan, and cohort can all behave differently.

A business like this may still become excellent. A 4.6+ store rating, hundreds of active subscribers, meaningful reviews, and a user story about losing 24 kilograms are real signals of product value. But value to users must be translated into a repeatable, positive-margin system before the founder can call it a durable business.

The bigger lesson for AI subscription apps

The most important takeaway is not “never buy ads” or “AI is too expensive.” It is that AI products often compress the distance between engagement and cost.

Every useful interaction can make the product better for the user while making the margin worse for the company. A successful onboarding flow gets more people to their first result—but may trigger more paid model calls. A generous free tier boosts app-store reviews—but may attract users who never pay. Better ads increase installs—but can magnify losses if the optimization event is disconnected from retained revenue.

That is why AI app unit economics must be designed, not discovered after the fact. The product team, growth team, and finance spreadsheet need to use the same definitions of activation, payer, proceeds, cost to serve, and retention.

For this solo developer, shutting down paid ads is a sensible next move because it isolates the core business. If organic users continue to arrive and the company can maintain enough margin after AI costs, the app has a foundation to improve. If demand drops, the founder will at least know the next problem is distribution rather than an illusion created by cheap-looking campaign metrics.

The post should be required reading for builders who see €22,000 in gross revenue and assume the hard part is over. In mobile AI subscriptions, the hard part begins when the customer pays: keeping them, serving them economically, and proving that the next acquired user improves cash flow rather than deepens the loss.

FAQ

What are AI app unit economics?

AI app unit economics measure how much profit or loss an app generates per user or customer after store deductions, taxes, acquisition costs, model inference, infrastructure, support, refunds, and other direct costs. For subscription apps, the analysis should include retention and renewal behavior, not just first payments.

Why can an app make revenue but still lose money?

Gross revenue is reduced by app-store commissions, VAT or sales taxes, refunds, cloud costs, AI model usage, subscription tooling, and customer acquisition spending. If those costs exceed net proceeds, the company loses money even when customer billings look strong.

How should an AI app calculate customer acquisition cost?

Use the acquisition cost tied to the business event that matters: ideally a paying and retained customer, not an install or app open. Calculate it by channel and cohort, then compare it with net customer contribution after store deductions and AI serving costs.

Should a new app turn off unprofitable paid ads?

Often, yes—unless the spend is explicitly capped as a learning or validation budget. Turning ads off can reveal whether organic demand, store rankings, referrals, retention, and product value are enough to support the business without subsidized installs.

How can AI apps lower inference costs without hurting quality?

Start by measuring request-level costs and quality outcomes. Then test model routing, caching, image optimization, deterministic lookups for common tasks, free-tier limits, confidence-based fallbacks, and lower-cost models against a structured evaluation set before changing the customer experience.

AI App Unit Economics: Why €22K in Revenue Still Lost Money