The analytics stack a multi-product indie hacker needs

From the SoleOS answers series — written about our own product space; grounded in published definitions and documented behavior, never invented numbers.

A multi-product indie hacker needs four data sources — payments, mobile subscriptions, web/product analytics, and search visibility — plus one place that rolls all of it up by app. That's it. You don't need a different BI tool for every product, and you don't need to log into ten dashboards every Monday morning.

The mistake most solo founders make isn't picking the wrong tools. It's picking good tools per-product and never building the layer that lets you compare products against each other. Let's fix that.

Start with what you're actually trying to answer

Before touching a single tool, write down the three questions you actually need answered every week:

1. Which products are growing, flat, or dying — right now?
2. Where is revenue actually coming from (Stripe vs. app stores), and does it match?
3. Which product deserves my next hour of work?

If your stack can't answer these in under 15 minutes, it's the wrong stack — no matter how many charts it has. This is also why a 15-minute weekly portfolio review is a useful forcing function: it exposes gaps in your data before they cost you a quarter.

Layer 1: payments (the ground truth for revenue)

Stripe is the source of truth for web/SaaS revenue. Not RevenueCat, not your own database — Stripe's ledger, because it's what actually moves money.

Two things matter here:

• Track gross volume and net revenue separately. Refunds, disputes, and Stripe fees eat into what you actually keep, and conflating the two makes your margins look better than they are.
• Give any external tool read-only access. You should never need to hand out a secret key with write permissions just to see a number go up.

If you're running subscriptions across multiple Stripe accounts (one per product, which is common and sane), you need a way to see them side by side without switching accounts constantly.

Layer 2: mobile subscriptions (RevenueCat, App Store, Play Console)

If any product is mobile-first with in-app purchases, RevenueCat is close to mandatory — it normalizes App Store and Play Store receipts into one subscription model so you're not reconciling two different billing systems by hand.

But RevenueCat and Stripe will rarely show the same MRR number for the same product, and that's normal, not a bug. App Store and Play Store take their cut before RevenueCat ever sees the money, timezones and billing cycles don't align perfectly, and refunds propagate on different schedules. We wrote a full breakdown of why Stripe and RevenueCat MRR numbers don't match — worth reading before you assume one of them is "wrong."

Also connect App Store Connect and Google Play Console directly if you can. They give you install counts and gross sales that RevenueCat sometimes lags on, and they're free.

Layer 3: product and web analytics

This is where founders overspend. You do not need GA4, PostHog, Mixpanel, Amplitude, and Hotjar running on a five-user side project. Pick one:

• GA4 if your products are mostly marketing-site + signup funnels and you want something free that plugs into Search Console.
• PostHog if you want session replay, feature flags, and event-level product analytics, and you're comfortable with a steeper setup.

Don't run both on the same product expecting matching numbers — they count visitors differently (cookie-based vs. fingerprint/identity-based, different bot filtering, different session timeout windows), and chasing parity between them is a waste of an afternoon. Pick the one that answers your actual question and move on.

For backend signals — new signups, webhook events — Supabase and Firebase projects can push events directly rather than you polling their consoles. That matters more than it sounds: a signup notification the moment it happens is worth more than a chart you check three days later.

Layer 4: search visibility (if you have any organic traffic at all)

Google Search Console and, if you care about Bing/Edge traffic (more than people think, especially in the US), Bing Webmaster Tools. Both are free, both take five minutes to set up, and both tell you whether your content is actually being found before you spend more time writing it.

The layer most people skip: the rollup

Here's the actual gap. Once you have Stripe, RevenueCat, PostHog/GA4, and Search Console connected across five, ten, or fifteen products, you have data. You don't have information. Nobody can look at fifteen separate dashboards every week and form an honest opinion about which product to kill and which to double down on — the context-switching cost alone eats the insight.

Three ways founders solve this, roughly in order of effort:

A spreadsheet. Genuinely fine below 3-4 products if you're disciplined about updating it. It breaks down once you're pulling numbers from five+ sources by hand every week — the manual entry itself becomes the reason you stop checking. See SoleOS vs. a spreadsheet for where the line usually is.

Looker Studio or a BI tool. Powerful, free-ish, but you're building and maintaining the connectors, the joins, and the definitions yourself. Fine if you enjoy that work or already have it built.

A portfolio dashboard. This is the category SoleOS is in, so — full disclosure — this post is written by SoleOS about its own space, and we're not going to pretend it's the objectively correct answer for everyone. If you run one or two products, or you genuinely like maintaining a spreadsheet, you probably don't need it. SoleOS exists for the specific pain of running 5-20 products and needing them normalized, compared, and forecast in one place without rebuilding connectors every time a tool changes its API.

Concretely, that means connecting Stripe, RevenueCat, PostHog, GA4, Search Console, Bing, App Store Connect, Play Console, Firebase, and Supabase once, and getting consistent MRR, growth, and traffic definitions across every project — see the metrics dictionary for the exact formulas used, because "growth rate" and "MRR" mean subtly different things depending on which tool computes them. You can also just poke at the live demo with sample data before connecting anything real, and the connectors page lists exact OAuth scopes and how to revoke them if you're cautious about access (you should be).

What a lean stack actually looks like

For a founder running, say, six products — three SaaS, two mobile apps, one content site:

• Stripe (all SaaS products) — revenue ground truth
• RevenueCat (both mobile apps) — subscription normalization
• GA4 or PostHog (pick one per product type, don't mix on the same product)
• Search Console (content site + any SaaS with organic traffic)
• A rollup layer — spreadsheet, Looker Studio, or a tool like SoleOS — reviewed weekly

That's five to seven connections total, not fifteen tools. The stack should shrink your weekly review time, not add another dashboard to check.

Frequently asked questions

Do I need GA4 and PostHog for every product?

No — pick one per product based on what you need to answer. GA4 is better for marketing funnels and free organic traffic tracking; PostHog is better for in-product behavior and feature usage. Running both on one product to "cover your bases" mostly produces two numbers that don't match and no extra insight.

How do I reconcile Stripe and RevenueCat if they disagree?

Expect them to disagree slightly and define which one is authoritative for which purpose: Stripe for actual cash collected, RevenueCat for subscriber counts and mobile-specific churn. See tracking Stripe and RevenueCat together for a deeper walkthrough of reconciling the two.

At what point do I need a rollup tool instead of a spreadsheet?

There's no fixed number, but most founders feel the pain around 5-6 products when manual data entry starts taking longer than acting on the data. If you're spending more time copying numbers than deciding what to do with them, that's the signal.

Is it safe to give a third-party tool access to Stripe and RevenueCat?

Yes, as long as you're granting read-only scopes and can revoke access at any time. Check exactly what a tool requests before connecting — the security overview and connector scopes are the right places to verify this for any tool, not just SoleOS.

What does SoleOS actually add on top of these connectors?

Normalized metrics across all connected products (so "growth rate" means the same thing everywhere), a single weekly view instead of N dashboards, and forecasting that needs at least 21 days of data to produce a projection with any confidence. If you only run one or two products, the spreadsheet template linked above will get you most of the way there for free.