Most CMSs sort themselves by what you are building. There is a blogging CMS, an e-commerce platform, a docs tool, an events product. Each one is excellent at its category and awkward outside it, which is why organisations end up running four of them and reconciling the logins.
Birkly has no categories. There is a collection, an entry and a field, and what you build is a matter of how you arrange them. This post walks six arrangements to show what that actually means — including where you hit the limits of the core.
A blog
posts, authors, tags. One blog-post.html template serves every entry that will ever exist in the collection.
This is the smallest useful Birkly site and the one worth understanding first, because everything else on this list is a variation of it. Note what is absent: no plugins, no page-per-post, no build. Publishing an entry makes it live because the template resolves against the collection at request time.
3 collections, 1 template, core only.
An online shop
products, variants, orders, customers, discounts.
The interesting claim here is that an order is not a special object. It is an entry with fields, in a collection, sitting next to your blog posts in the same admin. A product with variants is a product entry with a variants sub-collection — the same ownership relationship as an author with posts.
What the core cannot do is take money. Cart, Stripe checkout, subscriptions and licence keys come from the Commerce plugin. But Commerce adds a payment pipeline on top of your data; it does not move your catalog into a proprietary structure. If you removed the plugin tomorrow, the products would still be there, in the same shape, readable by the same templates.
5 collections, core + Commerce.
A social feed
profiles, posts, follows, reactions.
This is the arrangement that surprises people, because a social product feels like it should need a different kind of system. It needs two things the core has: sub-collections for the ownership relationships (a profile has posts, a post has reactions) and a way for people who are not staff to write.
That second part is the User Management plugin — registration, tiers, permissions — combined with public form submissions landing in the approval queue. Someone can contribute to your site without ever seeing the admin, and what they write waits for review in exactly the same queue an AI agent's draft waits in.
4 collections, core + User Management.
An event site
events, venues, tickets, rsvps.
An event is an entry with a date, a venue reference and a capacity. Note the reference: a venue is used by many events and is not owned by any of them, so it is a flat collection rather than a sub-collection — the distinction we worked through in the piece on nested entries.
Free RSVPs arrive through a public form straight into a collection. Charge for a ticket and Commerce handles the checkout. The event entry does not change shape when money enters the picture, which is the property that makes the free-then-paid transition a configuration change rather than a rebuild.
4 collections, core + Events (+ Commerce for paid tickets).
Documentation
sections, articles, versions, faq.
Docs are where nesting earns its keep: sections contain articles, articles carry versions, three levels deep. The sidebar tree in your template is the storage tree, so rendering it is a walk rather than a reassembly.
The part that has no equivalent elsewhere on this list is the Agent Guide, which exposes that tree as grounded context. An AI answering a question about your product reads your actual documentation rather than inferring from your homepage. No plugin required — it is core.
4 collections, core only.
A portfolio
projects, clients, media, services.
Projects reference clients, clients reference projects, and media lives in one library that both pull from. The mutual reference is the giveaway that neither owns the other.
4 collections, core only.
What this buys you and what it does not
The payoff is that the second thing you build costs less than the first. Having modelled a blog, you have already learned the shop — not analogously, literally. Same admin, same template syntax, same MCP tools, same approval queue. Three of the six sites above need no plugins at all.
The cost is that Birkly will not beat a specialist product at its own game on day one. A dedicated e-commerce platform has a decade of edge cases in its tax engine that Commerce does not. A dedicated docs tool has search behaviour we have not built. If you are running one thing and only ever one thing, and that thing has a mature category leader, the honest advice is to look hard at the category leader.
Where the general model wins is when you are running several things, or when what you are building does not fit a category cleanly — which, in our experience, is most real projects. A catalog with editorial content. Events that are also a membership. Documentation that is also a product marketing site.
You can try the six arrangements on the homepage, and the docs walk the first build step by step. Birkly is free and open source at release — join the waitlist.