Simple architecture on purpose — built for today.

The core idea is simply simple. Birkly did not take shortcuts in development — no hiding complexity behind endless packages, libraries, or package-manager layers — so the vision can become reality: fair, open technology that is clever enough for humans and clear enough for AI. A dependency-light core stays secure and extensible; power comes from plugins, templates, and field types you choose. Developers and AI work against something readable, not a maze — and you are not locked into our front-end when you already have a stack you like.

The artificial intelligence user

Birkly treats connected AI like any other actor in the system: it is a user with roles and permissions, not a magic backdoor. You bring your own provider (OpenAI, Anthropic, Google, …) — you pay your bill, you pick the vendor, and the CMS stays neutral.

Its capabilities are only what you assign. It does not get to bypass that because it is an API.

The architecture stays deliberately simple — structured content, collections, and APIs are easy to point at. That is what “simple enough for AI” means here: fewer mistakes, less guessing, outputs that map to real fields and entries. Clever where you need roles and approvals; straightforward where the model just needs to read the system. Admin chat and MCP hooks follow the same rule: help where it helps, humans before anything ships.

From the ground up — without the stack

Birkly is rethought without the usual shortcut: stacking package managers, frameworks, and libraries until nobody knows what the project actually depends on. Instead: flat files, a straight PHP core, readable templates — proven technology that can look “old-school” on paper until you operate it against today’s problems; then the trade-off makes sense. The system stays clean, manageable, extensible, secure, and robust because the foundation stays small. Dependency-free, or as close as we can honestly get, is a pillar — fewer holes from other people’s packages, less maintenance theatre, less setup pain. Anything extra is opt-in, not inherited.

Templates: plain English, real routing

The templating engine is a little different on purpose: you wire a project in securely with one script and whitelisting — no mystery handshake. The language reads almost like plain English, so you are not locked to pure developers only; founders, business owners, designers, and marketers can change what they need without pretending to be ops. Example: a post.html can drive all blog posts and route URLs automatically. Templates pull data from the CMS and push work back without ceremony. And if you already have a front-end or stack you like, you can skip our rendering layer and use the API only — no cage, no forced toolchain.

Plugins, field types, real features

Extensions are how the product grows without bloating the core: plugins carry metadata and settings schemas, field types can be auto-discovered (PHP, plus JS/CSS when needed), sub-entries handle hierarchy, and public submissions get rate limits and moderation so the front door does not become a spam hose. The point is the same as everywhere else in Birkly — add capability in modules you can see and remove, not hide it inside “the platform.”

The admin — designed as a product, not an afterthought

As founder and designer, the admin is where most of the product work had to land. I started with information architecture — how collections, entries, settings, and permissions connect, and what someone should see on day one versus month three. From there: layout, typography, spacing, and a small design system so the interface stays calm and consistent. Not a theme slapped onto features; an admin that feels designed for people who publish, moderate, and configure things every week.

The harder flows got the same treatment: approvals, AI connections, moderation, nested content — the places CMS panels usually turn into icon soup. Clear states, readable permissions, shared patterns between lists, editors, and settings so you are not re-learning Birkly on every screen. Field layouts and editor chrome are tuned for long sessions, not demo screenshots. Less noise than most backends; more room for the actual work.

The result — and where this goes

Put together, Birkly is a CMS you can own: files on disk, a core you can still read, extensions you can add or remove, AI that behaves like any other user — with approvals before anything goes live. Developers keep their stack; the API stays yours. The foundation stays manageable and secure because it was kept simple on purpose, not because we promised it in a deck.

Longer term, I see Birkly as a European-based project at the intersection of AI and digital infrastructure — open source, fair technology, not another walled garden. The ambition is to change how we build web projects: less toolchain theatre, more structure that teams, tools, and models can actually work with. Clever where humans need judgment; simple enough where AI needs clear fields, permissions, and trails. No shortcuts in how it was built, so the end product vision has a chance to become real — not another CMS that only looks good in screenshots.

What comes next is shipping, polish, and real-world proof. If you are wrestling with the same questions — product shape, CMS architecture, AI that has to behave — I am always up for that conversation.