AIKit uses its open-source EmDash project as the top-of-funnel for enterprise sales — developers try the free CMS, build plugins, and their organizations upgrade to paid when they need SSO, white-label, or support SLAs.
The model is simple: give away a genuinely excellent product and let organizational need drive the upgrade. No enterprise cold outbound. No demo-bloat. The product itself becomes the salesperson, and the developer who deployed it becomes the internal champion.
The Problem
Enterprise sales for a CMS and plugin platform is brutally expensive. The conventional SaaS playbook — LinkedIn outreach, Salesforce sequences, conference booths, multi-month proof-of-concept cycles — burns six figures before a single enterprise deal closes. Each enterprise opportunity can cost $5,000–$15,000 in sales engineering time, trial infrastructure, and executive bandwidth before anyone writes a check.
For a developer-tools company like AIKit, the math is even worse. Developers hate being sold to. Cold outreach to engineering leaders gets ignored. Conference demos feel performative. The traditional enterprise sales machine creates friction, not trust.
AIKit needed a channel that pre-qualified leads: developers who already know the product, have built on it, and are advocating internally. The goal was to make the enterprise sale start at the "how do we buy this?" question rather than the "who are you?" question.
The Solution
The open-source EmDash project IS the sales channel. There is no separate marketing funnel, no lead-nurture sequence, no SDR team. The entire go-to-market strategy is a single MIT-licensed GitHub repository.
Here is how it works in practice:
A developer discovers EmDash on Hacker News, GitHub trending, or through a blog post. They clone the repo, run `npm install`, and have a working CMS in under ten minutes. No demo request form. No sales call. No credit card.
The developer builds a prototype — maybe a documentation site for their team, maybe an internal tool dashboard. They discover the plugin API and build a custom integration. They deploy it on Cloudflare. Their team starts using it.
At some point, the team hits a ceiling. They need:
| Feature Need | Developer Action | AIKit Response |
|---|---|---|
| Single sign-on (SSO) | GitHub Issue: "How do we add SAML?" | Links to enterprise pricing tier |
| Multi-site management | GitHub Discussion: "20 sites, one dashboard?" | Docs page on multi-tenant deployment |
| Audit logging | Email: "Compliance requires logs" | White-label enterprise option |
| Support SLA | GitHub Issue: "Need guaranteed response time" | Enterprise support contract |
At this point, the developer is no longer a prospect — they are an internal champion. They have already invested hours building on EmDash. Their team depends on it. Switching costs are real. The question is not "should we buy?" but "how fast can we approve the purchase order?"
The developer writes the internal justification document. They compare the free open-source tier against the enterprise features. They argue that the team already uses the product, it works, and the upgrade is the obvious path. AIKit just provides the pricing page.
Architecture: OSS-to-Enterprise Funnel
The funnel has five stages, and no salesperson touches the first four:
1. **Discovery.** GitHub repo (EmDash) appears in search results, social media, or aggregator sites. The README is the landing page. Clear, concise, with a working demo link.
2. **Evaluation.** `npm install emdash` — the developer has a running instance in ten minutes. No auth wall. No signup form. The friction is zero.
3. **Commitment.** The plugin API allows developers to extend EmDash for their specific needs. Building a custom plugin creates investment. The developer now has code that depends on EmDash.
4. **Internal advocacy.** The developer deploys to Cloudflare and shares with their team. Colleagues start using it. The deployment moves from experimental to critical.
5. **Purchase.** An organizational need (SSO, compliance, support) triggers the upgrade. The developer initiates the purchase conversation internally and reaches out to AIKit through the GitHub Issues page or the enterprise link in the footer.
```
GitHub → npm install → Plugin API → Team Deploy → Enterprise Buy
(free) (10 min) (investment) (viral) (upgrade)
```
Each stage is automated. GitHub Actions, issue templates, and the README handle everything before stage five.
Implementation
AIKit made deliberate implementation decisions to make this funnel work:
**MIT License.** EmDash is MIT-licensed on GitHub. No dual-license confusion, no source-available restrictions. Commercial use is explicitly allowed. This removes the first objection a developer might have.
**Enterprise section in README.** The README has a clear "Enterprise" section with a link to the pricing page. It is visible but not obtrusive — no popups, no banners, no interruptive calls to action. The link lives alongside the installation instructions and the API documentation.
```markdown
Enterprise
Need SSO, audit logging, white-label branding, or a support SLA?
[Explore enterprise plans →](https://aikit.dev/enterprise)
```
**Intelligent issue routing.** GitHub Issues with the "question" label trigger an auto-reply workflow that links to the relevant docs and FAQs. Enterprise-related keywords ("SSO," "SAML," "compliance," "support SLA") trigger a separate workflow that tags the issue for a human follow-up within 24 hours.
**CONTRIBUTING.md.** The contributing guide explains both code contributions AND how to reach the team for commercial needs. It sets expectations: open-source contributions are welcome, and the team is available for enterprise conversations.
**GitHub Actions pipeline.** A workflow scans new issues and discussions for enterprise signals. When detected, it:
1. Adds an "enterprise" label
2. Posts a comment with the pricing page link
3. Notifies the sales channel in Slack
The sales team only engages when the signal is clear — the issue history shows the developer already knows the product.
Results
The OSS-to-enterprise funnel produces measurable results:
| Metric | Value |
|---|---|
| Enterprise leads originating from open source | 70% |
| Average GitHub user to enterprise deal cycle | 45 days |
| OSS-originated deal close rate vs. cold outbound | 2x faster |
| Developer-written internal justification docs per deal | ~1 (the champion writes it) |
Two data points stand out:
**45 days from GitHub to close.** This is remarkably short for enterprise SaaS. Traditional enterprise sales cycles for developer tools average 90–180 days. The difference is that the product evaluation happens before the sales conversation starts. By the time AIKit talks to procurement, the technical decision is already made.
**2x faster close rate.** Open-source-originated deals close twice as fast as cold outbound. The reason is trust. The developer has already used the product in production. They are not buying a promise — they are buying a known quantity. The sales conversation is about pricing and terms, not features and validation.
Key Takeaways
Open source is the most authentic sales channel for developer tools. It works because it aligns incentives: the developer gets a free, high-quality product, and AIKit gets a pre-qualified, low-CAC enterprise lead.
**Don't upsell in the README.** The README is documentation, not a sales page. Enterprise links should be visible but secondary. The product sells itself — let it.
**Make the upgrade path visible but not invasive.** An "Enterprise" link in the footer, not a banner. A section in the README, not a modal. The developer should discover the enterprise option naturally, not be interrupted by it.
**GitHub stars are a vanity metric; GitHub Issues conversations are the real pipeline.** A repo with 1,000 stars and no Issues yields zero leads. A repo with 500 stars and active Issues — questions about deployment, feature requests, configuration help — is a sales engine. Every issue is a signal of engagement. Every discussion is a potential deal.
**The developer champion does the hard work.** AIKit does not need to build a 50-page sales deck. The internal champion — the developer who deployed EmDash and got their team using it — writes the justification, handles the technical evaluation, and pushes through procurement. AIKit's job is to make the product excellent and the upgrade path clear.
The Bottom Line
AIKit's enterprise sales channel is a GitHub repository. No Salesforce sequences, no SDR team, no conference booth budget. Just an MIT-licensed open-source project that developers love, with a clear upgrade path when organizational needs exceed what the free tier provides.
The model works because it respects the developer: give them a great product, let them build on it, and be there when their organization needs more. Every GitHub clone is a potential enterprise deal. Every plugin built is a lock-in that benefits both parties. Every "how do we deploy this at scale?" issue is a qualified lead, ready to buy.
That is the power of open source as an enterprise sales channel.