PostHog vs Plausible for a Solo App: When Product Analytics Becomes the Outage

You added analytics to learn which button matters. Six months later the tracking script is your slowest third-party, the self-hosted PostHog box is paging you for Redis, or the privacy-friendly Plausible bill climbed with traffic you cannot convert. Product analytics becomes the outage—either for users (performance) or for you (ops).

PostHog and Plausible answer different questions. This is which one a solo app should pick when the goal is learning without inheriting a second product to operate.

What each is optimizing for

Plausible is privacy-first web analytics: pageviews, referrers, goals, light script, simple dashboard. You learn traffic shapes without a surveillance warehouse.

PostHog is a product analytics suite: events, funnels, session tooling, feature flags, experiments—especially potent self-hosted or cloud when you need product depth beyond pageviews.

If you only need “where did traffic come from and which pages matter,” Plausible’s restraint is a feature. If you need “where do users drop in onboarding,” PostHog’s depth is the point—and the cost.

When analytics becomes the outage

• Heavy JS delaying LCP on a marketing page
• Self-hosted PostHog disk/CPU eating the same VPS as the app
• Event volume exploding after you instrument everything “just in case”
• Debugging tracker blockers instead of shipping
• Dashboards nobody checks while invoices arrive

Choose Plausible when

• Marketing site + simple SaaS marketing metrics
• You want GDPR-friendly defaults without a science project
• You will not staff event taxonomy design
• Performance budget is tight

Choose PostHog when

• You need funnels, cohorts, flags, or session context tied to product events
• You will maintain an event schema
• You accept cloud cost or dedicated ops for self-host
• Insights change weekly shipping decisions

Self-host PostHog realism

Self-host only with a dedicated box and backups. Sharing the app VPS couples deploys to analytics failures. If analytics downtime can take the app down, you designed an outage.

Instrumentation diet

Track fewer events with clearer names. A hungry PostHog with 200 junk events is worse than Plausible with 5 goals. Taxonomy is product work.

Decision guide

Plausible for calm traffic truth. PostHog for product depth you will operate. If analytics is already the outage, cut events, lighten scripts, or split hosts before you add another tool.

Cost shapes that surprise solos

Plausible’s pricing is mostly traffic-shaped and predictable. PostHog cloud can jump when event volume jumps—especially if you track every hover. Self-host PostHog trades invoice spikes for ops spikes. Model cost as either money or nights, not as free.

A useful exercise: estimate events per active user per week. Multiply by growth you hope for. If the number scares you, either diet events or pick Plausible for the marketing surface and a thinner product tool later.

Privacy postures

Plausible markets cookieless simplicity. PostHog can be configured carefully but invites richer identifiers because product analytics wants them. Match legal posture and personal ethics to the tool. Do not install PostHog session tools on a blog that promised minimal tracking.

Performance budgets

Measure LCP with and without the script on a cold mobile connection. If marketing conversion drops from a heavy SDK, you bought analytics that fights acquisition. Load product analytics after auth when possible; keep the public site light.

Operational failure modes

Self-hosted PostHog: disk full, migrations, clickhouse-ish resource needs depending on version/architecture, backup neglect. Cloud PostHog: bill shock, misconfigured sampling. Plausible: fewer ops, less depth, goal setup still requires discipline.

If you already under-maintain the app VPS, do not put PostHog on it.

A pragmatic split

Plausible on the marketing site. Product events only after login via a carefully chosen tool—sometimes PostHog cloud with a hard event budget, sometimes first-party logs into your own warehouse later. Splitting surfaces prevents one philosophy from taxing both.

Decision checklist before installing anything

Write down the three questions you need answered this quarter. If they are all traffic questions, install Plausible. If two are funnel questions, consider PostHog with a written event list of ten or fewer. If you cannot name three questions, install nothing yet—guessing creates the outage later.

Add a kill criterion: if the tool is not opened for fourteen days, uninstall or downgrade. Dashboards that exist for comfort still cost CPU and money.

Finally, separate marketing and product surfaces in your head before you separate them in code. That mental split prevents a session-replay SDK from landing on a docs site that only needed referrer stats.

Solo apps die from distraction as often as from competition. Analytics should reduce distraction by answering a short list—not become the product you run instead of the product you sell.

When product analytics becomes the outage, the fix is usually subtraction: fewer events, lighter scripts, dedicated hosts, or a calmer tool. Addition is how you got here.

Event taxonomy for people who hate process

Write events as verbs on objects: signup_started, signup_completed, project_created, export_clicked. Avoid page_view_special_2. Version names if you must change meaning. Delete events you have not queried in 60 days. PostHog rewards this discipline; without it you drown.

Plausible goals should map to business moments: signup page thank-you, pricing CTA, docs search. If you cannot map a goal to money or learning, skip it.

Team of one on-call

You are the SRE for whatever you self-host. If PostHog pages at 2 a.m., will you get up? If not, buy cloud or use Plausible. Heroic self-hosting without on-call willingness is cosplay.

Compliance theater versus real promises

If your privacy policy says minimal tracking, honor it in the script tag. Tools are not moral. Configurations are. Screenshot your live network waterfall quarterly and reconcile with the policy page.

Migration notes

Moving from PostHog to Plausible means losing funnel history—export what you need first. Moving from Plausible to PostHog means designing events before flipping the switch or you will collect junk for months. Dual-running briefly is fine; dual-running forever is how pages get slow.

The outage postmortem template

When analytics hurts users or ops, write five lines: symptom, tool, volume, host shared?, fix (diet/split/remove). Keep the notes. Patterns emerge—usually “too many events on shared VPS.”

Keep the template next to your pricing notes. Analytics decisions are business decisions wearing engineering costumes. The costume is optional; the bill and the LCP regression are not.

If you are early and pre-product-market-fit, prefer Plausible or even server logs. Depth tools reward retention work. Before retention exists, depth is a toy. Toys become outages when they share a CPU with checkout.

After fit, revisit. Many solos correctly start calm and later graduate a slice of product analytics—without dragging session replay onto the marketing homepage. Graduation is allowed. Homogeneous tool religion is not required.

Ask quarterly: did any chart change a decision? If no, shrink. If yes, invest in the taxonomy that made the chart trustworthy. Trustworthy beats comprehensive.

That is the solo-app rule. Comprehensive analytics on a one-person team is how product analytics becomes the outage you debug instead of the feature you meant to ship Tuesday.

Ship Tuesday. Measure lightly. Expand only when a named question is worth the ops or the invoice. PostHog and Plausible are both fine tools aimed at different hungers—feed the one you have, not the one a Twitter thread said you should want.

Concrete setups that stay sane

Docs + marketing site: Plausible only. No session replay. Goals on signup and pricing.

Authenticated app with onboarding friction: PostHog cloud, ten events, flags optional later, never on the public blog.

Homelab curiosity project: neither, or server logs. Your side project does not need a warehouse.

Regulated niche: lean Plausible or first-party only; read counsel before PostHog-style depth.

Write the setup name in your README so future you does not “just add PostHog” on a bored Sunday.

Bored Sundays create outages. Named setups prevent them. Pick PostHog or Plausible with a setup name, a kill criterion, and a host that is not also your checkout box—and analytics stays a sensor, not the fire.

If the fire is already lit—shared VPS thrashing, LCP ruined, bill shocking—subtract first. Move analytics off the app host, drop unused events, replace a heavy snippet with Plausible on public pages. Only after the fire is out should you debate PostHog depth again. Sequence saves solos from cleverness.

Cleverness is optional. Uptime and a fast first paint are not. Treat analytics as a guest in the house of your product, not as the landlord.

Landlord analytics evicts trust. Guest analytics answers the three questions and leaves room for the product. PostHog or Plausible—pick the guest that matches the visit, set a checkout time with your kill criterion, and do not renew automatically just because the dashboard still looks impressive at midnight.

Midnight impressions are not metrics. Morning decisions are. Build for morning.