KnowledgePeak.ai

Why I built it

I spent a decade teaching enterprise support organizations to write good knowledge articles. The methodology works — but it arrives wrapped in KCS training programs, coaching networks, and content standards that assume you have staff to dedicate to it.

Small businesses have exactly the same problem and none of that scaffolding. They need a troubleshooting article, an FAQ, a policy document. What they usually produce is a wall of prose that answers no specific question, because nobody told them that the structure is the part that matters.

KnowledgePeak encodes the structure so the user doesn’t have to know it.

The core design decision

The obvious version of this product is a text box that says “describe your article.” I deliberately didn’t build that, because a blank prompt puts the burden of knowing what good looks like back on the user — which is the actual problem.

Instead, each document type has a guided questionnaire derived from the article structures I used in enterprise KCS practice. A troubleshooting article asks about the environment, the symptom, the cause, and the resolution as separate inputs. The questionnaire is the methodology: by the time you’ve answered it, the structural work is done, and the model is filling in well-scoped sections rather than inventing an entire document shape.

That’s the thesis I’ve argued in writing for years — AI output quality is mostly a knowledge-structure problem — implemented as a product rather than a conference talk.

Architecture worth noting

Provider-agnostic generation. An LLMService layer sits between the article generator and the models, currently routing to OpenAI or Grok. Swapping or adding providers doesn’t touch generation logic.

Prompts as data, not code. Templates, system prompts, model configuration and SEO directives live in Postgres and are editable through an admin panel, with hardcoded fallbacks if the database is unavailable. Improving output means editing a record, not shipping a release — the same reasoning behind putting knowledge content in a CMS instead of hardcoding it.

Export that matches reality. Generated articles are editable in a rich-text editor and export to TXT, Markdown, DOCX and PDF, because documentation has to land wherever the team already works.

Usage accounting. Generation is metered per user against tracked usage records, with the schema in place for subscription billing.

Current status

Live and functional — generation, editing, export, auth, and admin configuration all work. Billing integration is partially built: the schema and customer fields exist, the webhook handling doesn’t yet. I’d rather say that plainly than imply a finished commercial product.