There is a moment every few years when you open the admin of the CMS you chose three years ago and realise you no longer understand it. A plugin you never installed is asking for a licence key. The editor has a new AI button that costs €19 a month. The upgrade notes mention a breaking change in a package you have never heard of, pulled in by a package you did not choose, required by the framework you did not pick.
Birkly started at one of those moments.
The three bargains we stopped accepting
Content management in 2026 offers you a choice between three bad deals, and most teams take one without noticing they had options.
The hosted bargain. Someone else runs it, someone else owns the database, and your content lives at the far end of an API you do not control. It is genuinely convenient right up until pricing changes, the free tier closes, or you want to leave and discover that export means a JSON file with your media as broken URLs.
The framework bargain. You self-host, but the price of admission is a build pipeline, a node_modules directory measured in hundreds of megabytes, and a dependency tree you are now responsible for auditing. The CMS is fine. The forty layers under it are what wake you up at 2 a.m.
The plugin bargain. The core is free and does about sixty percent of what you need. The other forty percent is a marketplace of plugins of wildly varying quality, each with its own update cadence, its own security posture, and its own opinion about how your database should look.
Every one of these bargains trades away the same thing: your ability to open the system, read it, and know what it is doing.
What we wanted instead
The specification was short, and every line of it was a reaction to something that had gone wrong on a real project.
It has to run anywhere. A €3 shared host. A Raspberry Pi. A locked-down server inside a hospital network with no outbound internet. That rules out anything requiring a build step at deploy time, which rules out most of the modern stack.
It has to be readable. Not "well documented" — readable. A developer who has never seen the codebase should be able to open a file and follow the control flow without a map. That constraint is what pushed us to plain PHP with no framework and no runtime dependencies, a decision we wrote about separately because it deserved its own argument.
It has to be usable by people who are not developers. The person writing the content is usually not the person who built the site. If the CMS only makes sense to the second group, the first group ends up emailing Word documents.
It has to treat AI as a first-class reader. Not a chatbot in the sidebar. Agents are already reading your site and answering questions about your product, correctly or otherwise. A CMS built in 2026 should have an answer for that at the architecture level.
Four people, one instance
The thing that made the design click was giving up on the idea of a single user. Birkly has four readers, and they all open the same instance.
The developer wants files, version control, and no magic. They get plain PHP, a project folder they can commit, and a template language with no hidden control flow.
The editor wants to publish without filing a ticket. They get an admin where collections, entries and fields are the only concepts they need to learn, and where publishing does not trigger a deploy.
The visitor wants the page to load. They get server-rendered HTML with no client-side framework between them and the content.
The agent wants structure. It gets MCP tools for reading and writing, and an Agent Guide that states, in machine-readable form, what your products are and what claims you actually stand behind.
Most CMSs are built for one of these and then apologise to the other three. Designing for all four from the start changes what the primitives have to look like — which is why there are only three of them.
Three primitives, no escape hatches
A collection is a named set of entries. An entry is a set of fields. A field has a type. That is the whole content model.
There is no separate concept for a page, a post, a product, or a taxonomy term. A blog is a collection called posts. A shop is a collection called products with a collection called orders next to it. Documentation is a collection of sections with articles nested inside. The engine does not know or care which of these you are building, and it does not have a different code path for any of them.
This sounds like a limitation until you try to do something the CMS did not anticipate. In a system with special-cased content types, the answer is a plugin or a hack. In a system with three primitives, the answer is usually just another collection.
What we are promising, and what we are not
Birkly will be free and open source at release. Not free-tier, not open-core-with-the-good-parts-paywalled: the core CMS — collections, entries, templating, admin, roles, MCP, Agent Guide — is free forever and the source is yours to read, fork and run.
The Hub is where the money is, and we would rather say that plainly than bury it. Commerce, Automation, Events, Studio and the site packs are paid or freemium plugins on top of a core that works without any of them. If we ever need to move something out of the core to make the business work, we will have failed at the thing this whole project is about.
What we are not promising: that it does everything today. Birkly is in alpha. Some of what is on the product page is shipping, some is in flight, and the roadmap is public specifically so you can see which is which before you commit anything to it.
This blog is where the working-out happens — the decisions, the trade-offs we got wrong the first time, and the parts we are still arguing about internally. If that is the kind of thing you want to read, join the waitlist. Alpha invites go to that list first.