We Didn't Build a CMS. We Built Full-Stack Apps.
The industry is wiring conversation onto CMS dashboards. Boomlink went the other way: not a CMS at all. Every site is a full-stack app with its own embedded database, built from templates and isolated plugins.
The industry right now is moving fast in one direction. WordPress.com, Framer, and the major platforms are wiring MCP integrations so AI agents can manage existing sites through natural conversation. The workflow is: chat with Claude or ChatGPT, and those agents take actions on your existing CMS. That is not a criticism. It is a reasonable response to what users already have.
We went a different direction, and it started with a decision about what we were building at all. Not a CMS. Not a page in a content model. A full-stack app with its own database.
What the retrofit integrations have in common is that the CMS is still the CMS. The conversation is a new way to drive it, but the underlying model (pages, posts, draft states, publish buttons, version diffs) remains the authority. An agent speaks; the dashboard listens; the interface is still the interface. WorkOS put it plainly in early 2026: the industry is moving from "apps with AI" to "AI with apps," with conversation becoming the layer that sits in front of everything.[2] That framing is accurate. It also still describes a world where the app is the thing being wrapped.
What changes when the thing you ship is not a page in a content model, but an application with real data behind it? That is the question we started with.
What the rest of the industry is actually building
In March 2026, WordPress.com announced that AI agents (Claude, ChatGPT, and others) can now create and manage content directly on WordPress.com sites through natural conversation: 19 new writing abilities across posts, pages, comments, categories, tags, and media. New posts default to draft, and explicit human approval is required before changes take effect.[1]
That design choice is telling. The draft and approval safety step exists because the underlying model (the WordPress post, the page, the published/draft binary) is what actually holds the site's state. The conversation can touch it, but the conversation is a remote control for a content repository. You are sending instructions to a system whose unit of value is managed content.
This is not a flaw in the retrofit approach. For the hundreds of millions of sites already on WordPress.com, meeting people where they are is the right call. The distinction we are drawing is about the unit of value. A CMS assumes the deliverable is managed content: pages, posts, publish states. We assumed something different. The deliverable is a full-stack app with its own ledger of data.
Why we started from a full-stack app instead
The honest answer is that we started by watching how AI-native operators actually work, and "managed content" was not what they were trying to produce.
What we kept seeing: operators do not think in pages-and-publish-states. They think in "I need a live thing for this business" and "it has to capture leads and keep the data somewhere I can read it." The workflow is not editorial. The intent is a working product. A page is only the front of it. The substance they need is an application: forms that capture submissions, a database the data lives in, a public endpoint they can read it back from.
The market gave external signal that AI-native building is becoming mainstream. Lovable, one of the larger natural-language-first builders, reported adding $100M in a single month in early 2026, reaching roughly $400M ARR with 146 employees.[3] Those are company-reported figures via TechCrunch; we treat them as directional, not audited. The direction is clear: building software by describing it is not a niche behavior anymore. The open question is what the output actually is. Builders that generate the whole site as fresh code hand you something fragile, a codebase that only holds together until the next change. That is the failure mode we designed against.
The architectural decision we made is that the substance should be durable, not generated from scratch each time. You start from a real full-stack template with its own embedded database. An isolated plugin system does the heavy functional work. Your AI writes only the thin frontend and the BFF, and makes the edits, through MCP inside ChatGPT or Claude. Boomlink sits between AI vibe-coding and WordPress: more reliable than generated code, more modern and isolated than a shared-runtime plugin ecosystem.
We want to be precise about the claim. Boomlink is not a CMS with a chat box, and it is not an AI that writes your whole site. It is a plugin-and-template platform where the templates and plugins carry the weight and the AI edits a thin layer. The philosophical framing is ours; the architecture underneath it is real.
What Boomlink actually is
Three things are true by design. Each one is a decision.
A full-stack app, not a page. Every Boomlink site ships with its own embedded database and a public data endpoint reachable with a site API key. The unit of value is an application with data, not a document in a content repository. That is the line that separates us from a CMS.
Isolated plugins, not a shared runtime. Features come from a sandboxed plugin system, so plugins add capability without the conflicts and security sprawl of a shared-space ecosystem. The functional substance is durable and reusable, not re-generated per prompt.
A super-app dashboard, not a deleted one. We did not remove the dashboard. We made it a super app. Every plugin and template renders as an embedded widget in one cockpit, and forms, analytics, A/B testing, custom domains, version snapshots, and the site's data all live there. Creation and editing are agent and MCP operable inside ChatGPT or Claude; the web and native apps are where you run and measure the result.
If you have read about why the production step is the bottleneck for non-technical operators, this is the reason that bottleneck shrinks. You are not assembling a page and hoping it holds. You start from a working app and edit a thin layer over durable substance.
What we learned about how operators actually work
Some of what the design choice revealed was validating. Some of it was genuinely surprising, and we would rather be honest about both.
The pattern that fit the thesis most cleanly: operators want a live, working product fast, and they want the data it collects to be somewhere real. Starting from a full-stack template with an embedded database matched that directly. They were not trying to manage content. They were trying to run a business function.
The thing that challenged us: operators still wanted a place to see and steer the whole thing, not just talk to it. That is exactly why the app is a super-app dashboard rather than a pure chat surface. Agent-first creation through MCP is the primary path, but the cockpit (widgets, live data, analytics, A/B testing, version snapshots) is where trust is actually built. Some operators lean on the conversation; others live in the dashboard. We built for both on purpose.
The tradeoff is real and we are still tuning it. Agent-operated creation asks people to extend trust to a process they cannot fully see, and the dashboard is how we earn it back. We are not reporting this as solved. It is the honest counterweight to the design stance.
There are two real answers to the same question about what an AI-native site platform should be. You can retrofit conversation onto a CMS that already exists: add capability without asking users to change their mental model, meet the install base where it is. That is a legitimate bet, and the major platforms are making it well.
Or you can decide the deliverable is not managed content at all, but a full-stack app with its own data, built from durable templates and isolated plugins, with AI editing the thin layer. That is the bet we made. It is not a CMS, and calling it one would describe the wrong thing.
Neither choice is obviously right. The question worth asking is what each one assumes the user is actually trying to ship. That assumption drives everything downstream. The one-source-of-truth model is only as useful as the substance it maintains.
If this framing changed how you are thinking about the question, pass it to someone else building in this space.
References
- WordPress.com Blog, "AI agents can now create and manage content on WordPress.com" (published 2026-03-20, updated 2026-05-15). 19 new writing abilities across posts, pages, comments, categories, tags, and media; new posts default to draft with explicit human approval required before changes take effect. https://wordpress.com/blog/2026/03/20/ai-agent-manage-content/
- WorkOS Blog, "The shift from apps with AI to AI with apps: Why your next app should live inside Claude" (2026). Strategic framing: "from apps with AI to AI with apps"; "the battle isn't whether AI is embedded in your app … it's whether your app can embed in AI." References the 2026-01-26 Anthropic/OpenAI MCP Apps announcement. Attribution: WorkOS; strategic claims are opinion, not independently verified. https://workos.com/blog/building-mcp-apps-inside-claude-chatgpt
- TechCrunch, "Lovable says it added $100M in revenue last month alone, with just 146 employees" (published 2026-03-11). Company-reported figures: ~$400M ARR, +$100M in a single month, 146 staff. Reputable outlet reporting vendor-stated numbers; not independently audited. Used as directional market signal only. https://techcrunch.com/2026/03/11/lovable-says-it-added-100m-in-revenue-last-month-alone-with-just-146-employees/