Build your own help text editor?
A JSON file with keys and strings, an endpoint that serves it, and a small admin screen behind your existing login. Two days of work, maybe three, and your help text is out of the release cycle. Every developer who has looked at this problem has drawn that sketch, and the sketch is correct.
The question is not whether you can build it. It is what you have signed up for after the two days.
What the first version does
It works. Text lives in a table, a screen edits it, your application reads it by key, and a change is live without a deploy. For twenty strings maintained by one developer, that may genuinely be the end of the story, and the rest of this page does not apply to you.
What month two asks for
Each of these arrives as a small request. None of them is hard. Together they are the product you did not intend to build.
Publishing. The first time someone saves a half-finished sentence, it is live. So you add a draft state, then a publish action, then a way to see what is currently live versus what is being edited.
History. Someone overwrites a paragraph that took an afternoon to get right. Now you need versions, a way to look at the previous one, and a way to put it back.
Who did that. Two people edit, one of them is wrong, and nobody can tell which change caused the support ticket. You add an audit trail.
Missing keys. Your app asks for a key that does not exist, or exists but is unpublished, or existed and was deleted. Each case needs a defined answer, in every component that fetches text, and a way to see which keys your product asks for but nobody has written.
Caching. Reading the database on every render is fine until the page that shows forty tooltips. So you cache, and then you need invalidation, and then you discover that a change takes an hour to appear and nobody knows why.
An editor. A textarea produces one paragraph. Real help needs a list, a link, a warning that stands out, a step someone can follow. You either ship markdown and teach non-developers markdown, or you start integrating an editor, which is a project with its own release notes.
Access. The screen sits behind your admin login, so giving your support colleague access to fix a tooltip gives them access to your admin. Now you need a role, which means permissions, which means a permission model.
A second language. Everything above, times the number of locales, plus a way to see what is missing in which language.
Search. Once there are two hundred topics, the person editing cannot find the one they need, and neither can anything else you want to connect to it.
The real cost is the tail
The build is a fixed, visible, enjoyable cost. The tail is none of those things: it is a stream of small tickets in someone's sprint, forever, for an internal tool with one customer, no roadmap and no owner once the person who wrote it moves on.
That is where the arithmetic goes wrong in the estimate. Compare the two or three days to a subscription and building wins easily. Compare the sum of the small requests above, plus the year in which they keep arriving, and the comparison is different. Put your own day rate next to €40 a month and the number that decides is not the build, it is the tail.
There is a second cost that never appears in the estimate: the time between "this tooltip is wrong" and "this tooltip is fixed" while your internal tool lacks the one feature this particular fix needs.
When building it yourself is right
Build it when:
- your help text is a small, stable set of short strings, and it is going to stay that way;
- the content has to live in your own database because you join it with something else;
- you have constraints that rule out an external service: on-premises only, an air-gapped environment, a regulator who must approve every processor;
- one developer owns both the content and the code, and nobody else will ever need to edit;
- you enjoy this kind of thing, and the maintenance is a hobby rather than a cost.
Those are real cases. If one of them is yours, Firebase Remote Config is worth reading first, because it removes the storage and delivery half of the build while leaving you in control of everything else.
When it is not
Do not build it when the reason is that buying looks expensive and building looks free. The build is the smallest number in that comparison, and it is the only one anybody estimates.
How to manage in-app help sets out the four levels this decision sits in, from strings in your repository to content a writer publishes alone. What HelpCCMS costs is the other side of the arithmetic.