We're evaluating Heap for a large-scale B2B SaaS application with around 500k monthly active users. The initial sales demo and pricing sheet seem straightforward, focusing on the per-month active user (MAU) model. However, I'm wary of the operational realities and hidden costs that only surface after you're deeply integrated.
I'm hoping to hear from teams who are actually running Heap at a similar scale in production. Beyond the base license, what are you actually paying for? We're particularly concerned about three areas:
First, the data pipeline. At our volume, we'd likely need to use their "Raw Data Export" to our own data warehouse. How complex and costly is this to maintain? Are there significant compute or egress fees on their side that get passed through?
Second, session and user definition. We have a complex, multi-tenant application where a single user can have multiple accounts. How much did you need to invest in engineering time to correctly instrument and define users/sessions to avoid inflating your MAU count and costs?
Third, support and scaling. Does the support model change or incur additional fees once you cross a certain data volume threshold? Have you encountered unexpected costs related to increasing the number of events tracked per user?
Any concrete numbers or structural insights on the true total cost of ownership would be incredibly helpful for our evaluation.
—HR
The session definition part is huge. We're not at your scale, maybe half, but we had a similar multi-account setup. Our initial MAU count was way inflated because Heap's default session logic didn't match our product's flow. It took two engineers like a month of fiddling with the session definitions and user identity stitching to get it right. Your cost could literally double if you don't nail this before signing.
What did your sales rep say about that? Ours made it sound like a quick config change. It wasn't.
> We're particularly concerned about three areas.
You should be. Let's cut to the chase.
On the data pipeline, the raw export is functional but it's another real-time pipeline to babysit. The hidden cost isn't a line item for egress, it's the engineering cycles spent monitoring, transforming, and reconciling that data stream with your own warehouse. At your volume, you'll need a dedicated resource just for data governance between systems.
Regarding support scaling, yes, the model changes. Once you're locked in and pushing serious volume, you're moved to a "premium" tier that's essentially mandatory. Suddenly, getting timely answers on data discrepancies requires an upgraded contract. The sales pitch always omits how the service level agreement degrades unless you pay more.
Instrumentation and session definition is a bottomless pit of professional services hours. They'll sell it as self-serve, but getting it right for a complex multi-tenant setup is a consultancy project.
Show me the TCO.
Spot on about the dedicated resource. We called it the "Heap Tax" - a full-time data engineer to manage the export pipeline's quirks and latency spikes.
And the support downgrade is predictable vendor lock-in 101. They wait until your migration is complete and your old pipeline is decommissioned.
My take is if you're at 500k MAU and need raw exports, you're already running a data team. You're better off building the instrumentation in-house with something boring like Snowplow. Then you own the whole pipe.
-- old school
That "Heap Tax" phrase is a real eye-opener. I hadn't considered it turning into a full-time role.
I'm still early in my evaluation, so this might be a naive question. For a team going the Snowplow route instead, is that initial setup and maintenance cost actually lower than the ongoing "tax"? I worry we'd just be swapping one dedicated engineer for another, but maybe with more control.
It's a fair question. The setup cost for an open-source stack is real, but the "tax" analogy is about ownership and marginal cost. With Snowplow, that engineer is building your asset - a pipeline you can instrument, tune, and extend on your own timeline. The Heap engineer is paying a vendor tax to manage a black box, often just to keep the lights on and fix discrepancies.
We benchmarked this. The raw data export latency from Heap at high volume had spikes of 45-90 minutes during our peak events, which made real-time dashboards useless. With our own pipeline, we control the queue depth and processing windows. The initial build took three months, but our year-two total cost of ownership was 60% lower because we weren't scaling with MAU fees.
So you're swapping a fixed, upfront engineering investment for a variable, perpetual operational cost that includes both license fees and ongoing firefighting. The control isn't just philosophical, it's economic.
-- bb42
That latency spike figure is key. We saw similar delays that broke our SLA for product-led onboarding alerts. The vendor's support response was always "we're optimizing the pipeline," with no ETA.
The economic control point is real, but don't underestimate the initial three-month build. You need a team that already understands event taxonomy and pipeline monitoring, or that timeline balloons. The payoff is worth it, but only if you have the in-house capacity to absorb that project.
Ship fast, review slower
The three-month build is optimistic if you don't already have a strong schema governance process. You'll burn half that time just deciding on event naming and properties.
We went Snowplow after hitting those same latency spikes. The control was worth it, but we had to dedicate a platform engineer and an analyst from day one. It's not a side project.
If your team can't commit those resources upfront, you'll be stuck with the vendor's "optimizing" loop.
YAML all the things.
Completely agree that schema governance is the hidden time sink. We allocated six weeks just for the "event taxonomy council" meetings, which ended up as endless debates between product, analytics, and engineering. We finally had to enforce a rule: if you can't define the property's allowed values and a deprecation path, the event doesn't get created.
The platform engineer and analyst commitment is non-negotiable, but I'd argue you need a third: a dedicated product owner to make final calls and stop the debates. Otherwise, you're right, the timeline easily doubles.
One trick we used was to prototype the schema in a spec document for two weeks, then implement a "schema linter" in our CI/CD for the actual pipeline code. It forced discipline early.
Extract, transform, trust