How to manage in-app help: the four levels

21 September 2026 · Most recent check: 20 September 2026

Where your in-app help lives decides who you need every time a sentence changes. There are four levels, from help text written into the code to help that a writer publishes alone. Most products sit at level 1 without anyone having chosen it.

The four levels

Level 1: help text in the code. The tooltip is a string in a component, the error message a constant in a file. Every change needs a developer, a review and a release. This is fine while the text rarely changes and the developer is also the person who explains the product.

Level 2: help text in a platform, pulled in at build time. The text lives in a translation or content platform and is copied into the app when it is built. Someone other than the developer can edit it, but the change reaches users with the next release. Most i18n setups work this way by default.

Level 3: help text fetched at runtime from a system built for developers. The app requests the text while it runs, so a change goes live without a release. A developer designs the structure, grants access and usually remains the person who makes the change. Firebase Remote Config sits here, as does a headless CMS in its default setup.

Level 4: help text fetched at runtime from a system built for the writer. The app requests each text by key. A writer edits and publishes without involving a developer, whose work ends once the keys are in place.

A headless CMS can move from level 3 to level 4 once a developer has built the content model, the editing views and a role that limits a writer to help text. That setup work is the real cost of a free tier.

Which level you are at

Two questions settle it. Who do you have to ask when a sentence in the product needs to change? And how long until the corrected sentence reaches users? If the answers are "a developer" and "the next release", you are at level 1 or 2.

What differs between tools

Tools differ on five points. Four of them are in this table.

Tool	Entry price	Priced by	Renders inside your app	Your app fetches text by your own key	Source text edited in
Elevio	$125/month, billed annually	Plan, seats and 1M page views	Yes, Elevio's widget	No; its API opens articles in Elevio's widget by Elevio's article ID	Elevio's editor
HelpHero	$55/month for 1,000 MAU	Monthly active users	Yes, HelpHero's overlay	No	HelpHero's editor
Userpilot	$299/month for 2,000 MAU, billed annually; Resource Center from $849/month	Monthly active users	Yes, Userpilot's widget	No	Userpilot's editor for flows; articles come from an external knowledge base
Intercom (Fin)	$29 per seat/month, billed annually	Seats, plus $0.99 per AI resolution	Messenger and a hosted help center	Only by Intercom's own article ID, server-side	Intercom's editor
HelpDocs	$99/month billed annually; $129 monthly	Plan and editors	Hosted help site	Through its article API	HelpDocs' editor
locize	$7/month	Usage	No	Yes, from a CDN	Usually your code; the platform holds translations
Tolgee	Free cloud tier; paid from €58/month, billed annually	Keys and seats	No	Yes, from a CDN	Usually your code; the platform holds translations
Sanity	Free tier; paid from $15 per seat/month	Seats and requests	No	Yes, through a query	Sanity Studio, once a developer has configured it
Firebase Remote Config	Free up to 100,000 fetches per day per project	Fetches	No	Yes	Firebase console
HelpCCMS	Flat monthly plan, see pricing	Plan; no MAU limit	No	Yes	HelpCCMS editor

Prices as published by each vendor on 20 September 2026. Sources are listed at the end.

Priced by. A tool that renders inside your app can count your users, and most of them price on that basis: HelpHero and Userpilot by monthly active users, Elevio by page views. Intercom is the exception. It prices by seat and meters its AI answers per resolution. A tool that only supplies text has no way to count your users.

Renders inside your app. Widget and overlay tools place the help for you, often without code. That is their main advantage. In exchange, their script decides what help looks like and where it can appear.

Your app fetches text by your own key. This decides whether help can appear exactly where your own code puts it: next to a field, inside an error message, in a panel you designed. Intercom's Articles API returns an article by an ID that Intercom assigns, so fetching by your own key means keeping a table that maps your keys to theirs.

Source text edited in. In most i18n setups, the source string is defined in code, for example as the default value in an i18next t() call, and the platform holds its translations. Some platforms, Tolgee among them, also let you edit the source language, but the value in the platform and the default in the code can then drift apart. When someone other than the developer writes the help, where the source is edited matters more than how it is delivered.

The fifth point does not fit in a column: the unit of content. Translation platforms are built around short strings and bill partly by volume. Knowledge base tools are built around articles. A tooltip of nine words and a task description of six hundred are rarely served well by the same tool.

When to stay where you are

Level 1 is the right place for a product with a few dozen short tooltips that change a few times a year, written by the developer anyway. Level 3 through Firebase Remote Config is a reasonable step if the app already uses Firebase and the texts stay short.

Moving up pays off when support tickets show that users do not understand parts of the product, and the person who can fix the explanation is not the person who can change the code.

Sources

Move your existing help text in →