Why in-app help vendors charge per MAU
Buy a tool that shows help inside your product and the bill arrives per monthly active user. HelpHero, Userpilot, Product Fruits, Jimo, UserGuiding, Chameleon and Appcues all price that way, with different words for the same unit. It looks like an industry habit. It is closer to a consequence.
The vendor is in your page
These tools work by running their own code in your application: a script tag, an SDK, a snippet in your layout. That code loads on every page view, decides whether this particular user should see a tour or a tooltip, and reports back what happened.
Three things follow from that, and all three lead to the same price model.
They can see your users. Their code runs where your users are, so the number is already there, and both sides can check it. A contract needs a unit that neither party has to estimate, and this category has one lying on the table.
Their costs move with your users. Every page view that loads their script is a request they serve, a targeting decision they evaluate and an event they store. Usage-based pricing is what you charge when your own bill grows with the customer's traffic.
The value moves with your users too. A tour that guides 100,000 people through signup is worth more than the same tour shown to 400. Vendors price where the value is, and in this category the value is measured in people reached.
None of that is unreasonable. It is the honest shape of a product that renders in someone else's interface.
What it means for you
The price follows your growth, not your content. Your help text does not change when your user base doubles. Your invoice does. In the published price ladders, the same set of tooltips goes from $55 to $299 a month between 1,000 and 20,000 users at HelpHero, and from $149 to $499 at Product Fruits. Those two are the vendors that print every step.
Above a certain size the price stops being public. At 20,000 monthly active users, two of the seven usage-priced tools we compared still publish a number. At 100,000, none of the usage-priced ones do. What you pay then depends on the negotiation.
Success is the thing that costs. The month your product breaks through is the month your onboarding bill jumps, which is a strange incentive to put on the tool that is supposed to help new users arrive.
The unit is not always the same word. Monthly active users, monthly tracked users, uniquely identified profiles. Read the definition before comparing two numbers, because a vendor that counts every visitor is not measuring the same thing as one that counts signed-in accounts.
The other shape
A tool that does not run inside your product cannot count your users, which means it has to charge for something else.
That is what HelpCCMS does. Your application fetches help text by key over a public API and renders it with your own components. We never see who read it, so the price is attached to the person who writes and publishes: one flat monthly plan, the same at 1,000 users as at 100,000.
The trade is honest and it goes both ways. Because nothing of ours runs in your page, we cannot place a tooltip for you, target a segment, run a tour, or report that a message was seen. That work stays with your developers, once, at integration time. What you get back is a price that does not move when your product does.
Which of those you want depends on what you are buying. If you need in-app targeting without developer time, per-user pricing is the cost of that convenience. If what you actually need is help text that someone can edit and publish without a release, you are paying for machinery you are not using. How to manage in-app help works through both cases, and what HelpCCMS costs has our side of it.
Sources
The price figures on this page come from the vendors' own pricing pages, read on 22 September 2026: HelpHero, Product Fruits, UserGuiding, Jimo, Chameleon, Userpilot and Appcues. The full comparison, with what each of them publishes at four sizes, is on the pricing page for in-app help tools.