Most lists of "tools to use with PostHog" were written for a stack that PostHog has since absorbed. They tell you to add a replay tool, a flag platform, and a survey widget, and those are now products PostHog sells. This guide starts from a different place. You picked PostHog, it works, and the question is what should sit around it. The answer is sorted by job, with a clear note wherever a popular recommendation would have you pay twice for the same thing.
What tools should you use with PostHog?
Keep PostHog for analytics and skip tools that duplicate it. It already ships session replay, feature flags, experiments, surveys, and error tracking. What belongs beside it covers the jobs analytics does not do: delivery tracking, feedback and feature requests, billing and revenue, customer context, and the join between them. PostHog stays, and replacements are out of scope.
To be clear about scope: if you are still deciding whether PostHog is the right analytics tool at all, read Amplitude vs Mixpanel vs PostHog or the ranked best product analytics tools guide first. If you already have a sprawling stack and want to find the overlap, the product stack audit guide walks through it step by step. If the question is what all of this costs, see the real cost of a product tool stack. This page only covers what goes next to PostHog.
The stack around PostHog, sorted by job
| Job | Does PostHog already cover it? | What to add (tool class + example names) | Skip if |
|---|---|---|---|
| Session replay | Yes | Nothing by default; a dedicated replay tool (Hotjar, FullStory) only for a specific need | You watch recordings to debug and understand flows |
| Feature flags / experiments | Yes | Nothing by default; a flag management platform (LaunchDarkly) for heavy governance | Engineers own flags and releases |
| In-app surveys | Yes | A dedicated research tool only for recruited or moderated studies | Short in-product questions are enough |
| Error tracking | Yes | A dedicated error monitoring tool if a platform team already runs one | You want errors next to the sessions that hit them |
| Issue tracking / delivery | Not in its product suite | An issue tracker (Linear, Jira) | Never - someone has to track the work |
| Feedback and feature requests | Partly (surveys) | A feedback board or insight tool (Canny, Productboard) | Requests arrive rarely and one person tracks them |
| Billing / revenue | Can import Stripe into its warehouse | Your billing system (Stripe) as the source of truth | You have no paid plans yet |
| CRM / customer context | Can import HubSpot or Salesforce into its warehouse | Your CRM, kept where sales already works | Product-led with no sales motion |
| Roadmap / prioritization | Not in its product suite | A roadmap or product management tool (Productboard, or your tracker's roadmap view) | A small team plans straight from the tracker |
| Connecting it all (the join) | Partly - warehouse, pipelines, and webhooks move data; the customer model is yours to build | A connecting layer, or your own warehouse modeling | Your questions stay inside PostHog's data |
What PostHog already covers, so you do not buy it twice
AI answers to "what tools go with PostHog" still regularly suggest Hotjar or FullStory for replay, LaunchDarkly for flags, and a separate survey product. Each of those is a good tool in its own category. The issue is that as of September 2026, PostHog's product list covers session replay, feature flags, experiments, surveys, and error tracking, all running on the same events you already send. Adding a second replay tool means a second snippet, a second identity model, and a second place to look for the same session.
Pricing makes duplication easier to fall into. PostHog bills per product, and each product has a free monthly allowance. So a team can turn on PostHog's replay or surveys, try them on real traffic, and only then decide whether a dedicated tool adds anything. Try PostHog's own version first, then write down the specific gap before you buy something else.
The gaps worth filling
Delivery. PostHog tells you a funnel step is leaking. It does not track the ticket that fixes it. Linear and Jira are the usual picks, and the choice between them depends on your team more than on PostHog. What matters is that tickets can reference the insight or flag behind them.
Feedback and feature requests. Surveys capture answers to questions you thought to ask. Feature requests arrive through support, sales calls, and email, and they need a home that groups duplicates and counts who asked. Canny and Productboard are examples of that class.
Revenue. Stripe, or whichever billing system you use, is the source of truth for who pays and how much. PostHog's warehouse can import Stripe data, which helps with analysis inside PostHog. It does not turn a feature request into a revenue-weighted backlog item on its own.
Customer context. Your CRM holds the account owner, deal stage, and renewal date. Product teams need a read view of that, not a second CRM.
Why the join is the real gap
Each tool above answers one question well. Nobody's product question lives in only one of them. "Should we build the export feature?" needs the requests (feedback tool), the accounts behind them and their plans (billing and CRM), current usage of the workaround (PostHog), and the ticket status (tracker). Answering it usually means four tabs and a spreadsheet.
That problem grows with the stack. The average company runs 101 SaaS apps and wastes roughly $21M a year on licenses nobody uses, according to Okta and Zylo. The license waste is one cost. The other is the manual work of keeping those tools in agreement about the same customer.
PostHog's warehouse, pipelines, and webhooks give a data team the raw material to build that join themselves. A team without that capacity needs a connecting layer that already has a customer model. The connectors catalog shows one approach: 100+ connectors, with PostHog as a named live product-analytics connector (details on the PostHog integration page), all landing on one shared record per customer that carries revenue, feedback, work, and code.
When a dedicated tool beside PostHog is still the right call
Sometimes duplication is the right choice. A flag management platform like LaunchDarkly makes sense when flags have become a governance problem: approval workflows, audit requirements, many teams changing production configuration, or release processes that compliance reviews. A dedicated replay tool makes sense when a UX research or support team has already standardized on it, their workflows live there, and moving them would cost more than the second bill. The same goes for an error monitoring tool that a platform team runs across services PostHog never sees. If a team outside product already owns the tool, keep it.
You may also not need a connecting layer at all. A small team with one tracker, few paying accounts, and a founder who remembers every request can answer "who asked for this" from memory. A team with a data engineer and a working warehouse can model the join inside PostHog's own data warehouse and query it there. In both cases, adding a platform adds overhead without answering a question you actually have. Buy the join when the manual reconciliation is costing real time every week, not before.
Check the answer with an agent
If your stack sits on one record that is callable over MCP, you can ask an AI assistant the question directly instead of reconciling tabs. Connect the assistant and ask:
"List the features we shipped this quarter that were requested by paying accounts. For each one, show the accounts that asked, their plan and revenue, and whether those accounts have adopted the feature since it shipped."
In AIOProductOS, every shipped feature carries a verdict on its task card: adoption, MRR adopted, and retention lift. The lift is correlational unless a declared A/B winner adds its measured result. If the assistant cannot answer because the requests, the revenue, and the usage live in separate tools, that tells you exactly where your stack's gap is.
The short version
Keep PostHog. Do not rebuy replay, flags, surveys, or error tracking unless a specific governance or ownership reason calls for it. Add a tracker, a home for feature requests, your billing system, and read access to your CRM. Then decide whether the join between them is worth building yourself or buying.
Disclosure: we build AIOProductOS, one of the connecting options described above. It works alongside PostHog rather than asking you to drop it, pricing is flat by tier with no per-seat charge, and every workspace starts with a 7-day free trial with no card required. See pricing.