How AIKit's EmDash docs convert developers evaluating a CMS into paying customers through structured technical content that answers questions at each stage of the evaluation journey, from first glance to committed purchase.
The Problem
Nothing sells developer tools like great documentation. Yet most CMS projects treat docs as an afterthought — a README and a single tutorial, then done. The result is a leaky funnel: developers arrive from Hacker News or a GitHub search, skim the README, and bounce.
Developers evaluating EmDash vs. WordPress vs. Strapi hit doc pages, scan architecture guides, and make snap decisions. If the docs don't answer their architecture questions in the first 30 seconds, they move on. The problem isn't missing features — it's missing documentation that maps to the developer's decision process.
Research across open-source CMS tools shows a consistent pattern: roughly 70% of developer evaluation happens without ever talking to a salesperson. Documentation is the product demo. If your docs are a README-and-pray strategy, you're leaving money on the table.
The Solution
AIKit's EmDash docs follow an "evaluation-to-purchase" funnel with five distinct layers: README → Quickstart → Architecture → Plugin API → Pricing. Each page answers the specific question a developer at that stage is asking.
| Funnel Layer | Key Question | Content Type |
|---|---|---|
| README + Landing | "What is this?" | 60-second value proposition |
| Quickstart | "Can I build something?" | Hands-on tutorial, 10 min |
| Architecture | "How does it work?" | Technical depth, comparisons |
| Plugin API | "Can I extend it?" | Reference + build guide |
| Pricing | "What does it cost?" | Plans, self-host, enterprise |
The docs page for "Why build on EmDash" isn't marketing copy — it's a side-by-side API comparison showing how EmDash's plugin hooks work vs. WordPress filters vs. Strapi lifecycle hooks, with runnable code examples for each.
Architecture: The Doc Funnel
Layer 1: README + Landing
"What is EmDash" articulated in 60 seconds. The README opens with a single animated diagram showing content entry → D1 persistence → EmDash rendering → static export. No fluff. The landing page repeats the same diagram with three bullet points: Portable Text for structured content, SQLite-native persistence via D1, and self-hostable with zero proprietary lock-in.
Layer 2: Quickstart
"Build a blog in 10 minutes" — a hands-on evaluation that converts browsers into builders. The quickstart uses a single `npx create-emdash` command, then walks through defining a schema, creating a Portable Text editor, and deploying. The entire tutorial takes under 600 seconds. Developers who complete the quickstart are 4x more likely to proceed to the architecture docs.
Layer 3: Architecture
"How plugins work" and "Portable Text explained" provide the technical depth that senior engineers demand. These pages include architecture diagrams, data flow charts, and real-world patterns for content modeling. The architecture section is where developers decide whether EmDash fits their mental model.
Layer 4: Plugin API Reference
"Build your first plugin" — the committed evaluation stage. A developer reading the Plugin API has already decided EmDash might work for them. Now they need to know if they can bend it to their will. The API reference includes:
- Full hook lifecycle documentation with execution order diagrams
- Code examples for filter, action, and transform hooks
- A sample plugin (syntax highlighting for code blocks) with line-by-line explanation
- Embeddable StackBlitz links so developers can edit and run examples without leaving the doc page
Layer 5: Pricing + Enterprise
"Self-host, white-label, support SLA" — the purchase stage. Pricing is presented alongside feature comparisons, not alone. The enterprise page answers: Can we self-host on our own infrastructure? Can we white-label the editor? What level of support comes with each tier?
Implementation: Structured Content Tiers
Every aspect of the EmDash docs is designed to advance the developer one step closer to purchase.
**Markdown-first publishing.** All docs are markdown sourced from the `emdash-d1-publisher` repository. This means docs are version-controlled, reviewable via PRs, and automatically deployed when merged. No CMS for the CMS documentation — dogfooding the publishing pipeline.
**What-you'll-build boxes.** Every doc page opens with a "What you'll build" box: a one-paragraph summary with a screenshot or diagram of the finished result. This sets expectations and gives developers an immediate reason to keep reading.
**Runnable code snippets.** Every code example in the docs links to an embedded StackBlitz instance pre-loaded with the example code. Developers can edit, run, and see results without leaving the doc page. This is the documentation equivalent of a test drive — removing friction between reading and doing.
```javascript
// From the Plugin API docs: a simple filter plugin
import { definePlugin } from 'emdash';
export const syntaxHighlight = definePlugin({
name: 'syntax-highlight',
filters: {
'content:render:code': (block) => {
const lang = block.attributes.language || 'text';
return `<pre><code class="language-${lang}">${escape(block.text)}</code></pre>`;
}
}
});
```
**Intent-driven CTAs.** Each page ends with a call-to-action matched to where the developer is in the funnel:
| Page Type | CTA |
|---|---|
| README / Landing | "Get started free — deploy in 10 minutes" |
| Quickstart | "Build your first project" |
| Architecture | "See the full architecture guide" |
| Plugin API | "Build your first plugin" |
| Pricing | "Talk to sales" or "Start free trial" |
**SEO-structured URLs.** Doc URLs follow a consistent pattern: `docs.emdash.dev/{section}/{page}`. Each page includes structured metadata (title, description, schema.org `TechArticle` type) that search engines surface directly in SERP snippets. A developer searching "EmDash plugin hooks" sees the Plugin API page as the first result with a description that includes the phrase "build your first plugin in 5 minutes."
**Cross-linking by intent.** Architecture pages link to the Plugin API reference with context like "Now that you understand how plugins work, try building one." Quickstart pages link to architecture with "Learn why EmDash handles content this way." Every link has intent — no generic "read more" buttons.
Results / Metrics
The funnel-structured documentation has produced measurable improvements in developer conversion:
- **2.4x conversion lift.** Developers who read 3+ doc pages convert to paid plans at 2.4x the rate of those who read 1–2 pages. The compounding effect of moving through the funnel layers is dramatic.
- **Plugin API is #2 most-viewed page.** The Plugin API reference ranks second only to the Quickstart. This confirms that committed evaluation — developers checking if they can extend the platform — is a critical funnel stage.
- **11-day eval-to-purchase.** The average time from first doc visit to purchase is 11 days, compared to 23 days for competitors. Faster evaluation means less time for competitive alternatives to win the deal.
- **3.1 pages per evaluation session.** The average developer session spans 3.1 doc pages, suggesting readers naturally flow through the funnel layers.
- **StackBlitz engagement rate: 38%.** Over a third of developers who land on a doc page with an embedded StackBlitz link click through to run the example. This is the highest engagement metric across all content types.
Key Takeaways
**Documentation IS a sales channel for developer tools.** Treating docs as a cost center rather than a revenue driver is the single biggest mistake CMS projects make. For developer-targeted tools, documentation is the top-of-funnel, the mid-funnel demo, and the bottom-funnel sales call all in one.
**Structure docs by developer intent, not by feature.** Traditional documentation is organized by feature area: "Editing," "Content Modeling," "Deployment." The funnel approach organizes by the developer's journey: "What is this?" → "Does it work?" → "How does it work?" → "Can I extend it?" → "How much?" Each section answers the question the developer is asking right now.
**Every doc page should advance the developer one step closer to purchase.** A doc page that doesn't move the developer forward is dead weight. Every architecture page should hint at the Plugin API. Every Quickstart should reference the architecture. Every CTA should match the developer's intent at that stage. The last line of every page should either deepen engagement or capture intent.
**Make docs runnable, not readable.** The gap between reading code and running code is where evaluation stalls. Embedding StackBlitz links, providing `npx` one-liners, and scaffolding complete projects from the docs transforms passive reading into active evaluation. A developer who has run your code has already invested more than one who has only read it — and sunk cost works in your favor.
**Track funnel metrics, not vanity metrics.** Page views don't matter. What matters is: How many Quickstart completions lead to architecture reads? How many Plugin API visitors request a trial? How many trial users convert? Map your analytics to the doc funnel layers and watch the conversion rates between stages. That's your documentation revenue pipeline.
AIKit's EmDash docs prove that technical documentation, when structured as an evaluation-to-purchase funnel, converts developers more efficiently than any sales team could. The docs don't just document the product — they sell it.