My four apps are LuminaClean (a photo cleaner), BookBinge (a reading tracker), Inkfall (an arcade game) and TicFlow (a habit and tic tracker). Checking several apps one tab at a time is a recurring complaint among indie developers; a March 2026 Show HN came from someone who got tired of checking five PostHog projects one at a time. My answer is a fixed weekly routine: the same seven numbers, in the same order, for calendar weeks. Below are the routine and the real numbers from the last five weeks.
Every number here leaves out my own test devices and pirated copies of the apps. I show counts and percentages, and changes in revenue rather than amounts.
One app pays for the other three
| App | What it is | Share of active users | Share of revenue |
|---|---|---|---|
| LuminaClean | Photo cleaner | 72.9% | 100% |
| Inkfall | Arcade game | 19.9% | 0% |
| BookBinge | Reading tracker | 5.0% | 0% |
| TicFlow | Habit and tic tracker | 2.2% | 0% |
Over the last 30 days, LuminaClean earned all of the portfolio's revenue with 72.9% of its active users. Inkfall had 19.9% of the active users and earned nothing. BookBinge and TicFlow are small on both counts and also earned nothing in that window.
Looked at on its own, Inkfall's user count reads as healthy. Next to the revenue share, it's the biggest open question in the portfolio. It's also why the routine below runs on LuminaClean first: it's the only one of the four that earned anything in the last 30 days, so it's where a change in downloads or conversion shows up as money.
The late-August pattern in LuminaClean
| Week starting | App Store downloads | Paywall viewers | New paying customers | Paywall to payer |
|---|---|---|---|---|
| Aug 17 | 43 | 33 | 2 | 6.1% |
| Aug 24 | 101 | 63 | 2 | 3.2% |
| Aug 31 | 45 | 41 | 0 | 0% |
| Sep 7 | 23 | 23 | 3 | 13.0% |
| Sep 14 | 29 | 35 | 5 | 14.3% |
Downloads in the week of September 14 were 71% below the late-August peak (29 against 101). Over the same weeks, the share of paywall viewers who became paying customers went from 3–6% to 13–14%, and the number of new paying customers went from 2 a week to 3 and then 5. Fewer people arrived, and more of the ones who did paid.
These are small numbers. Five of 35 is five people, and one payer more or less moves that week's rate by several points. Two weeks in the same direction tell me which way it's going; they don't give the app a new conversion rate.
The rows don't say why. Two explanations fit them: the late-August spike brought in people who were less likely to pay, which pushed the rate down as the base grew, or something in September made the paywall convert better. The first one would show up in installs by source for those weeks, so that's the next thing to check.
Why Monday-to-Sunday weeks instead of the last 7 days
The usual alternative is a rolling window: the last 7 days, recalculated every day. I use calendar weeks, Monday 00:00 to Sunday 23:59 in one timezone (Europe/Amsterdam for me), for four reasons.
- A finished week stops changing. The week of September 7 has the same numbers today as on the Monday after it closed, so I can compare it, write it down and put a note next to it. A rolling window changes every day, and two days in a row share six of their seven days, so most of its daily movement is one day dropping out and another coming in.
- Cohort numbers need fixed buckets. "New users who came back the next week" needs an arrival week and a following week. On a rolling window, the group you're measuring shifts every day.
- Things you do land in one column. A release, a price change or a new landing page sits inside one week, so the week before and the week after are easy to find.
- Day boundaries matter at small numbers. With 0 to 5 new paying customers a week, one purchase at 23:30 counted on the wrong side of midnight changes a week's rate. Pick one timezone and keep it. Apple's download counts arrive by Apple's own reporting days, so that one row can't follow your timezone.
The cost of calendar weeks is that they're late: on a Wednesday, the current week is two and a half days old. That's what the next rule is for.
Compare the week in progress with the same days of last week
Put a Wednesday-morning week next to all of last week and every count looks like a collapse. Compare Monday to Wednesday with Monday to Wednesday of last week instead. That keeps the two periods the same length and keeps weekday against weekday, so a busy Sunday is never set against a quiet Wednesday.
Use the week in progress to catch breakage early (downloads at zero, no paywall views after a release) and the closed weeks for anything you'd change in the app.
The seven numbers, in the order I read them
The order follows a person through the app: they arrive, open it, come back, pay. Then the money, then the website. Reading top to bottom means a change in revenue gets traced to the first row where it appears. These are LuminaClean's five most recent full weeks, each starting on the Monday shown. The second line in a cell is the change from the week before, or the count behind a rate:
| Number | Aug 17 | Aug 24 | Aug 31 | Sep 7 | Sep 14 |
|---|---|---|---|---|---|
| 1. App Store downloads | 43 | 101 +135% | 45 −55% | 23 −49% | 29 +26% |
| 2. New users | 80 | 115 +44% | 57 −50% | 37 −35% | 38 +3% |
| 3. Came back the next week | 7.5% 6 of 80 | 7.0% 8 of 115 | 8.8% 5 of 57 | 13.5% 5 of 37 | 13.2% 5 of 38, still counting |
| 4. Paywall to payer | 6.1% 2 of 33 | 3.2% 2 of 63 | 0% 0 of 41 | 13.0% 3 of 23 | 14.3% 5 of 35 |
| 5. Revenue, change | – | +59% | −55% | +116% | +48% |
| 6. MRR at week end, change | – | −4% | −24% | +5% | +40% |
| 7. Website visitors | 116 | 173 +49% | 182 +5% | 162 −11% | 296 +83% |
1. App Store downloads
What it tells you: how many people arrived. This is Apple's count of first-time downloads, by Apple's reporting days. Pirated copies never appear in it, since they don't come from the App Store.
The five weeks read 43, 101, 45, 23, 29. The spike in the week of August 24 (+135%) and the drop after it move most of the counts below: new users and paywall viewers rose and fell with it.
2. New users
What it tells you: how many people opened the app for the first time, counted by the app itself. It runs above downloads every week, and one reason is that someone who deletes the app and installs it again is a redownload to Apple and a new user to the app.
For LuminaClean: 80, 115, 57, 37, 38. Without the pirated-copy filter this row would be inflated: pirated copies were 10.1% of LuminaClean's new users in August (of 506) and 18.6% so far in September (of 161), and none of the 162 pirated users since mid-July has ever paid.
3. Came back the next week
What it tells you: whether the app stuck for the people who tried it. It's the share of a week's new users who were active at any point in the following calendar week.
LuminaClean's rate went from 7–9% in the August weeks to 13.5% and 13.2% in September, but the count barely moved: 5 to 8 people came back each week. The rate rose because fewer new users arrived. Read the count next to the rate, or a shrinking week looks like better retention. I don't have a benchmark for this number in a photo cleaner, so I only compare it with its own past weeks.
4. Paywall to payer
What it tells you: whether the offer works for the people who see it. It's new paying customers in the week divided by the people who saw the paywall that week. That makes it a weekly ratio rather than a tracked funnel: someone who sees the paywall on Sunday and pays on Monday lands in two different weeks. Over several weeks that evens out; in a single week it can move the rate.
The five weeks: 6.1% (2 of 33), 3.2% (2 of 63), 0% (0 of 41), 13.0% (3 of 23) and 14.3% (5 of 35). The pirated-copy filter matters here in some apps and not in others. In LuminaClean, 0.0% of the last 30 days' paywall views (of 357) came from pirated copies: the cracked copy apparently has the paywall removed. In BookBinge, 17.5% of paywall views (of 63) did, so its conversion would read 17.5% worse without the filter.
5. Revenue change
What it tells you: whether this week brought in more money than last week. It comes after the conversion rows on purpose: by the time I get here I already know whether more people paid, or the same number of people bought bigger plans.
Week over week, LuminaClean's revenue changed +59%, −55%, +116% and +48%. At this size, weekly revenue halves or doubles from one week to the next. A handful of purchases makes a week, and a yearly plan pays a whole year up front, so a few yearly buyers make a week lumpy.
6. MRR change
What it tells you: whether the recurring base grew. Monthly recurring revenue spreads each active subscription's price over a month (a yearly plan counts a twelfth of its price, a weekly plan about four times its price) and leaves out one-time purchases, as in RevenueCat's MRR definition.
LuminaClean's MRR at each week's end changed −4%, −24%, +5% and +40%. Read it next to revenue. In the week of September 7, revenue rose 116% while MRR rose 5%. Money that barely registers in MRR is one-time purchases or most of a yearly plan's price, which fits the jump in new yearly buyers in early September that also shows up in my month-forecast backtest. In the week of September 14, revenue (+48%) and MRR (+40%) moved together, which suggests new recurring subscriptions rather than one-offs.
7. Website visitors
What it tells you: whether the app's landing page is drawing people. It's the row most directly moved by a post, a shared link or a campaign.
LuminaClean's landing page had 116, 173, 182, 162 and 296 visitors. For this app, visitors and downloads don't move together. In the week of August 31, visitors rose 5% while downloads fell 55%; in the week of September 14, visitors rose 83% and downloads 26%. So visitors aren't a stand-in for downloads here, and how many downloads the site produced is a separate question that needs website-to-install matching. That's why it's last: it gives context for the top row rather than a result.
What the numbers changed about where my time goes
Only as far as five weeks and 30 days of data support:
- Revenue work goes to LuminaClean. It's the only app where more downloads or paywall views have turned into money lately: the other three earned 0% of the revenue in the last 30 days.
- In September, LuminaClean's weak row is downloads. Paywall to payer was at its highest of the five weeks while downloads were at their lowest (23 and 29). If the conversion holds, getting more people to the store page has more room to raise revenue than another paywall change. Both rates rest on 23 and 35 paywall viewers, so I treat that as a bet to check over the coming weeks.
- Inkfall needs its own test. 19.9% of active users and none of the revenue says it has an audience. It doesn't say whether that audience would pay, and LuminaClean's weekly rows can't answer that.
- No decisions from one week. One payer moves a week's rate by several points, so two weeks in the same direction is the least I act on.
All of this depends on behavior and purchases sitting on the same user record, which is what makes "paywall viewers who became paying customers" countable at all. The setup behind that is in why RevenueCat and your analytics numbers don't match. For why the revenue here is customer-paid money and not Apple's payout, see Apple payout vs App Store proceeds vs RevenueCat revenue.
FAQ
Why use calendar weeks instead of the last 7 days?
A finished calendar week stops changing, so you can compare it and write it down. A rolling window changes every day, and two days in a row share six of their seven days. Cohort numbers such as "came back the next week" also need a fixed arrival week.
How do you compare a week that isn't finished yet?
Compare the days so far with the same days of last week, for example Monday to Wednesday against Monday to Wednesday. A partial week next to a full one makes every count look like a drop.
What does paywall to payer measure?
New paying customers in a week divided by the people who saw the paywall that week. It's a weekly ratio, not a tracked funnel, so read it over several weeks with the counts next to the rate.
Should pirated copies be left out of weekly numbers?
Yes. In LuminaClean they were between 10.1% and 22.6% of new users per month since mid-July, and none of the 162 pirated users ever paid. Leaving them in inflates new users and dilutes every per-user rate.
How small is too small for weekly conversion rates?
There's no fixed cutoff. With 23 to 63 paywall viewers a week, one extra payer moves a week's rate by several points. Wait for two or more weeks moving the same way before acting.
Sources
- LuminaClean, BookBinge, Inkfall and TicFlow production data, pulled September 23, 2026, test devices and pirated copies excluded
- Hacker News, Show HN: I have 5 PostHog projects and got tired of checking them one at a time (March 2026)
- RevenueCat, Monthly Recurring Revenue (MRR) chart