Product Decisions This Supports
- Build vs. buy for in-product documentation: Deciding whether to hand-roll a docs surface (custom CP nav, markdown files in a repo, a Notion/Confluence link in the sidebar) or adopt a purpose-built addon that keeps docs inside the Statamic control panel where editors already work.
- Feature scoping for editor enablement: Whether "in-CP help / playbooks" ships in the current cycle or stays a wiki link. This addon gives you a cheap way to test the hypothesis that proximity to the editing surface reduces support load, without committing engineering time.
- Customer onboarding and handover packaging: For agencies and internal platform teams, a place to store client-specific editorial guidelines, content model explanations, and "how to publish X" runbooks next to the site they describe — useful as a deliverable in a handover, or as an internal artifact to cut repeat questions.
- Support-cost deflection: A low-lift bet against the recurring cost of answering the same editor questions in Slack/email. Success metric is inbound "how do I…" volume and time-to-first-publish for new editors, not feature completeness.
- Roadmap placement of a knowledge base: Informs whether internal docs deserve a first-class surface (search, versioning, permissions) or can remain a lightweight, flat-file convenience for a small team.
- Vendor/lock-in posture: Low strategic weight — content is markdown in the Statamic project, so an exit is mostly a content migration rather than a platform unwind. That makes it a reversible decision, which is itself a reason to trial it early.
Caveat for any of the above: adoption signal here is effectively zero (no stars, zero dependents, zero score). Treat every capability claim as unverified until you read the source and test against your Statamic version. Plan the decision as a time-boxed spike with a documented fallback, not a platform commitment.
When to Consider This Package
Consider it when:
- You are already on Statamic (confirm supported major versions — Statamic's addon APIs have moved across 3.x/4.x/5.x) and the team lives in the control panel daily.
- Your docs are internal, editor-facing, and small in volume — playbooks, field-by-field guidance, publishing checklists, style rules.
- You want docs versioned with the site in git alongside content and config, rather than in a separate SaaS.
- You can accept flat-file semantics: no rich query layer, no complex access control, no formal review workflow.
- A single maintainer / community addon is an acceptable risk for a convenience feature that is easy to rip out.
- You want to validate demand before asking engineering for a sprint — cheapest possible experiment.
Look elsewhere when:
- You need per-role visibility, audit trails, approval workflows, or full-text search — a wiki (Confluence, Notion, GitBook) or a bespoke Laravel module will serve better.
- The docs are customer-facing — you want a real docs site with search, versioning, and SEO, not a CP-internal surface.
- You are not on Statamic, or you are on a version the addon does not explicitly support.
- The maintainer shows no recent commits or no compatibility statement — do not put anything load-bearing on it; a broken addon after a CMS upgrade is a support ticket you own.
- Docs are large or multi-team — you will outgrow a flat-file approach quickly and pay twice.
Due diligence before adoption: last commit date, open issues, declared Statamic/Laravel version constraints, license, whether it registers a CP nav item and how it stores content (files vs. database), and whether removing it leaves content intact.
How to Pitch It (Stakeholders)
For executives: This is a small, reversible experiment, not a platform bet. It lets editors keep how-to documentation inside the tool they already use, which is a plausible way to cut onboarding time and repeat support questions. Cost is a day or two of evaluation, and the content is plain markdown that survives if we walk away. The package itself is an unproven community addon with no measurable adoption — so I am recommending a time-boxed trial with a clear success metric and a named fallback (wiki link or a small in-house page), not a standard.
For engineering: One dependency, one integration point, no database changes expected — but verify against our Statamic version and read the source before we commit. The real question is not "does the addon work" but "do we want a docs surface in the CP at all." The addon is the cheapest way to answer that; if the answer is yes and usage grows, we will likely replace it with something we control, and the markdown content carries over.
Ask: approval for a two-week spike, a success metric (support-question volume and new-editor time-to-first-publish), and agreement that we either promote this to a supported tool or remove it at the end of the window — no indefinite "it's just there" state.