You do not need to be an engineer to use Kookee, and you never need to open the codebase. Everything below happens in the dashboard.
Where content lives
Each project is organized by module: Blog, Changelog, Help Center, Pages, Announcements and Feedback. Pick the module, and you see everything in it — drafts included.
Which one to use is usually obvious from the writing itself. Announcements, product updates and support articles are different jobs, and keeping them separate is what lets your app show each in the right place.
Drafts and publishing
New entries start as drafts. A draft is invisible to the public API, the portal and your application — it exists only in the dashboard.
Publishing makes it live immediately. There is no build step and no deploy: your application and portal serve the new version on their next request.
This is worth understanding, because it means publishing is the moment of truth. Anything you would rather a customer not read should stay a draft until it is ready.
Unpublishing takes an entry back to draft, and it disappears from public view just as fast. Use it if something goes out early — it is a normal action, not an emergency one.
Writing the body
The editor handles headings, bold and italic, lists, links, quotes, tables, images and code blocks. Code blocks pick up syntax highlighting automatically.
Keep headings hierarchical — a heading level 2 followed by a level 3, not a jump to level 3 because it looked smaller. Headings are how readers scan, and they are also what search matches against.
Excerpt
The excerpt is the short summary shown in listings, search results and on cards. Write it deliberately.
If you leave it empty, listings show no summary at all: the API returns an empty excerpt, and the portal and the React components render nothing in its place. One clear sentence that says what the reader will get is worth the ten seconds.
Categories and tags
Categories are the navigation structure — one per entry, shown as sections. Keep the list short. Six categories that a reader can hold in their head beat twenty that make them hunt.
Tags are cross-cutting labels, and an entry can carry several. They work well for themes that span categories, like "billing" or "security".
Categories can be reordered, so put the ones new readers need first. Most help centers should open with getting-started material.
SEO fields
Meta title and meta description control how the entry appears in search engines and link previews. Leave them empty and the title and excerpt are used.
Fill them in when the natural title is not what you would want someone to see in search results — a playful headline might read well on your blog and poorly in Google.
Meta descriptions are capped at 160 characters, meta titles at 70, because that is roughly what search engines display.
Visibility
Entries carry a visibility setting. Public is the normal choice — the entry appears in listings, on the portal, and through the API.
If you are unsure what a non-public setting does on your plan, leave it public. An entry that is published but mysteriously absent from the portal is almost always one where visibility was changed.
Translations
If your project has several locales, each entry is written per language, and translations are linked together as a group.
When a translation is missing, readers see your default-locale version instead of an empty page. Useful, but it also means a half-translated site can look finished — worth checking which entries actually exist in each language rather than assuming.
Writing for search
Kookee's help center search matches on meaning, not just keywords. A reader searching "stop charging me" can find an article called "Managing your subscription".
The practical consequence: open an article by describing the problem in the words a reader would use, before introducing your product's terminology. "If you want to stop being billed" gets found by far more searches than "This article describes the subscription management interface" — and it is a better opening sentence anyway.
Watching what gets read
Blog posts, pages and help articles show a view count; changelog entries and announcements do not track views. For help articles, an article nobody reaches is a navigation or wording problem; an article everyone reaches that still generates the same support question is a content problem. Reactions on posts and changelog entries tell you which announcements actually landed.