The Wall Between Dev and Marketing
Every organization with a website has felt the friction. The development team owns the CMS infrastructure — deploying updates, managing plugins, keeping the site secure. The marketing team owns the content strategy — tracking SEO performance, monitoring conversions, planning campaigns. These two worlds rarely communicate, and the gap creates real problems.
Developers build dashboards in Grafana or Datadog. Marketers build dashboards in Google Analytics or HubSpot. Neither team sees what the other is doing. When a new SEO plugin ships, marketing doesn't know about it until someone mentions it in a Slack thread. When a content campaign drives a traffic spike, developers don't see it unless they happen to check the server logs.
AIKit's plugin architecture solves this by bringing the marketing dashboard directly inside your CMS — no separate tools, no API integrations, no data duplication.
The Plugin Studio Concept
AIKit runs on EmDash, but its architecture generalizes to any CMS that supports a plugin system. The core idea is simple: instead of bolting marketing tools onto the side of your site, run them inside the CMS itself.
Each AIKit plugin is a self-contained module that lives in a `plugins/` directory:
```
plugins/
auto-blog-seo/
src/
index.ts # Main plugin entry
dashboard.tsx # Admin UI dashboard widget
hooks/
onPublish.ts # Post-publish analytics
onSave.ts # Draft analysis
api/
routes.ts # API endpoints for dashboard data
schema.ts # Plugin configuration schema
```
This structure means every plugin can:
- Register dashboard widgets that appear in the admin UI
- Expose API endpoints for real-time data
- Hook into CMS events (publish, save, delete)
- Store configuration in KV or D1
The Hybrid Architecture
AIKit uses a hybrid architecture that lets developers and marketers work from the same data without stepping on each other.
Developer Layer
Developers interact with the plugin system through TypeScript APIs and configuration files:
```typescript
import { PluginConfig } from "@aikit/plugin-system";
export default {
name: "auto-blog-seo",
hooks: {
onPublish: async (entry, { env }) => {
await analyzeSeo(entry.content, env.DB);
await generateOgImage(entry, env.R2);
await submitToIndexNow(entry.slug, env);
},
},
dashboard: {
widgets: ["seo-score-trend", "content-gap-analysis"],
},
} satisfies PluginConfig;
```
Marketer Layer
Marketers interact through the admin UI dashboard — no coding required:
| Widget | Data Source | Refresh |
|--------|-------------|---------|
| SEO Score Trend | ec_posts + _emdash_seo | Real-time |
| Content Gap Analysis | LLM comparison | On-demand |
| Publishing Calendar | ec_posts | Auto-refresh |
| Traffic Estimates | D1 query (page views) | Hourly |
| Keyword Rankings | Plugin settings | Daily batch |
How Data Flows
The magic is in how data flows from development infrastructure to the marketing dashboard without intermediate tools:
```
[Developer pushes plugin update]
→ wrangler deploy (Cloudflare Workers)
→ Plugin registers hooks
→ Marketer sees new dashboard widget immediately
[Marketer publishes a blog post]
→ onPublish hook fires
→ Plugin runs SEO analysis
→ Score appears in dashboard
→ Developer can see SEO scores in new relic/logs
```
Real-World Example: Auto-Blog SEO Plugin
Let's trace through a concrete scenario. The Auto Blog SEO plugin uses AIKit's plugin architecture to monitor every published post:
1. A marketer publishes a new post titled "How EmDash Handles Content"
2. The `onPublish` hook fires inside the Worker
3. The plugin:
- Extracts the post content
- Sends it to an LLM for SEO scoring (title quality, keyword density, readability)
- Generates an OG image from the title
- Scores the post for AEO (Answer Engine Optimization) citability
- Stores the results in `_plugin_storage` KV
4. The SEO Score Trend widget updates in real-time
5. The developer sees the LLM API call in the Worker telemetry
Both teams see the same data, from the same system, without any glue code.
Why This Matters for Content Engineering
The term "content engineering" gets thrown around a lot, but it has a specific meaning: applying software engineering principles to content operations. AIKit's plugin architecture is content engineering in practice because:
- **Version control:** Plugins live in Git alongside the site code
- **CI/CD:** Plugin updates deploy through the same pipeline as site updates
- **Monitoring:** Plugin performance metrics feed into existing observability tooling
- **Testing:** Plugin hooks can be tested in isolation with mocked CMS events
Building Your Own Dashboard Widget
If you want to add a marketing dashboard widget to your EmDash site, here's the minimal setup:
```typescript
// plugins/my-metrics/dashboard.tsx
import { Widget } from "@aikit/dashboard";
export const PostCountWidget: Widget = {
label: "Total Published Posts",
query: `SELECT COUNT(*) as count FROM ec_posts WHERE status = 'published'`,
render: (data) => (
<div class="metric-card">
<span class="metric-value">{data.count}</span>
<span class="metric-label">Published Posts</span>
</div>
),
};
```
This widget queries D1 directly and renders inside the admin dashboard. No external API, no separate app, no iframe.
The Results So Far
After three months of running AIKit's plugin architecture across four sites (AIKit, CCFish, AiSalonHub, PlayableAd Studio):
- Publishing time dropped from 45 minutes of manual SEO work to under 30 seconds
- Content team can self-serve SEO scores without waiting for dev
- Developers see plugin health metrics alongside site health metrics
- Cross-team meetings about "what's on the site" dropped by 60%
The hybrid architecture doesn't eliminate the boundary between development and marketing. It makes the boundary transparent — both teams see through to the other side without needing to cross it.