DEV Community: Rakete

birkly.io is a normal site with a few special needs. Here is what it takes to build it.

Rakete — Fri, 25 Sep 2026 06:52:46 +0000

birkly.io is not an overcomplicated website. It has a contact form, a waitlist, donations, sponsor slots, and a club for members. What it does have, like most real projects, is its own special needs. Someone can donate any amount between €1 and €5,000, once or every month, appear on a public supporter list, and join the club with the same email. If they cancel a monthly donation, they keep their account. Only the supporter label on their profile changes.

This post is about why Birkly was built. birkly.io was the first real website made with it, and it proved the point: those special needs can stay part of one normal site.

On Birkly, that is what happened. The contact messages, waitlist entries, sponsor texts, and club posts are normal content. An automation sends the “you are on the waitlist” email, and another email later invites that group. A second automation updates the supporter label when a payment starts or a monthly donation ends. The club itself can be free, or people can join by donating. Free signup is turned off right now, so joining goes through the donation. Turning it back on does not remove the donation.

The only paid plugin is Commerce. During early access it costs €29.90 a month, or €24.90 a month if you pay yearly. The listed price next to that offer is €39.90 a month. You also need your own server. Card fees are Stripe’s usual fees.

An AI assistant can set this up with you. It can create the content, the forms, the emails, the donation, and the club, because those are the same buttons a person uses in the admin. Birkly does not charge extra for the AI. You can connect a free model from OpenRouter, or a paid one if you prefer.

On other systems, the same special needs are often the part that gets difficult, or impossible, without extra products or custom software. You can still launch something. It is usually a smaller version of the idea, because the tool only sells part of it.

The short version

Prices below are public prices from September 2026. Yearly prices are used when the company offers them. Dollar prices and euro prices are not the same currency. Card fees are extra.

Birkly.
Could you build birkly.io with it?
Yes. This is how it is built.
What would the closest possible solution cost?
€24.90 a month + hosting.

Shopify.
Could you build birkly.io with it?
No. Donation options are limited, and it has no community.
What would the closest possible solution cost?
About $123 a month, hosting included.

WordPress.
Could you build birkly.io with it?
Partly. Needs custom development to connect the plugins.
What would the closest possible solution cost?
About $44 a month + custom development + hosting.

Strapi.
Could you build birkly.io with it?
No. Needs a complete custom build.
What would the closest possible solution cost?
Custom development + hosting.

Webflow.
Could you build birkly.io with it?
No. It cannot do this donation, and it has no community.
What would the closest possible solution cost?
About $139 a month, hosting included.

Squarespace.
Could you build birkly.io with it?
No. No supporter list, and no community.
What would the closest possible solution cost?
About $113 a month, hosting included.

Shopify

Shopify can publish the pages, the contact form, and a waitlist. The Basic plan is $29 a month and includes hosting, automatic emails, and 10,000 emails a month.

It cannot take the donation the way birkly.io does. A small app, about $5 a month, lets someone type a one-time amount. A monthly donation has to be a fixed price, such as €5 or €15, not “any amount between €1 and €5,000.” Shopify also has no club with posts, comments, and a supporter label. For that you add another product, such as Circle, at $89 a month. Members then have a second login, separate from the shop.

You can launch a shop, a one-time donation, a few fixed monthly amounts, and a club on another site. That is a real website. It is not the same idea. The total is about $123 a month, hosting included. If you use Stripe instead of Shopify’s own payments, Basic adds an extra 2% fee.

Shopify’s own assistant, Sidekick, is included. It can help you set up the shop. It cannot add a donation or a club that Shopify does not offer.

WordPress

WordPress can end up doing the same things for visitors. It does not do them as one product. You install separate plugins, and someone has to connect them.

A free form plugin can take contact messages and sponsor enquiries. FluentCRM Pro, at $129 a year, can send the waitlist confirmation and the later invite. GiveWP Pro, at $399 a year, can take a custom donation amount every month through Stripe. BuddyBoss is free and can give members a profile, a feed, and a free registration.

These plugins do not automatically know about each other. A donation does not, by itself, create a club account, add the supporter label, or keep the account when the monthly donation stops. Someone has to build that link. The public list of supporters, with names and logos, is also something you add. The plugins are about $44 a month, plus the custom development that connects them, plus a server.

So the site is possible. The hard part is the link between “this person paid” and “this person is a member,” and you have to look after that link when the plugins update.

Strapi

Strapi is a content system. It can store pages, sponsor texts, and form entries. It does not include donations, waitlist emails, supporter labels, or a club.

To get the same website, a developer has to build those parts: the payment page, the emails, the rule that updates a member’s label, and the club with posts and comments. The Strapi license can be free. What you are paying for, in time or in money, is that custom development, plus hosting. A smaller version is Strapi for the pages, plus Circle at $89 a month for the community. Donors and members are still in two different places.

Webflow

Webflow can design the pages and the sponsor section. The Premium plan is $25 a month and includes hosting. It cannot take the birkly.io donation: any amount, once or every month, together with a public supporter list. It also has no club. Built-in member accounts, and this kind of monthly payment, have been removed.

A login tool such as Memberstack, about $25 a month, can hide pages until someone logs in. That is a locked page, not a club with posts and a supporter label. The waitlist emails need another tool, such as Zapier or Make.

The closest setup is about $139 a month, hosting included. That pays for the site, a login tool, and a separate club. The donation of any amount every month, and the supporter list, are still missing.

Squarespace

Squarespace includes hosting, the forms, and a donation block on the Basic plan at $16 a month. What it cannot do is the public supporter list with names and logos, or a community. Memberships can be free or paid, and they open pages, courses, and videos. They do not give members a feed, comments, or a supporter label that updates when a donation starts or stops.

The waitlist needs Squarespace Email, about $8 a month. A real club means a separate product such as Circle, at $89 a month, with its own login. Together that is about $113 a month, hosting included. The donation and the club still do not share one account.

If you still want the full idea

On the other systems, you can almost always build the missing parts yourself, inside the CMS or as a separate tool next to it. That work is expensive and slow, and it does not stop when the site goes live. Someone has to keep it working after release.

An AI that controls the screen can operate those systems too, because it can use the same admin a person sees. That ability costs money, and it also raises the chance of mistakes, opens more security gaps, and can expose private information to the AI provider. What it builds is still custom software, so the cost and the upkeep remain.

Birkly is the way through this without those compromises. The donation, the emails, and the club are already part of the product, and an assistant uses those same parts instead of building them, or taking over the whole screen to reach them.

Why this example exists

This is not a post against Shopify, WordPress, Strapi, Webflow, or Squarespace. They are capable products, and each one fits the people it was made for.

birkly.io is not a specially complicated site. It is a normal project with a few advanced needs, which is what most projects turn out to have. It was also the first real website built with Birkly, and building it showed why Birkly exists: so those needs can be met in the product itself.

Birkly was not made to copy birkly.io. It is meant to stay flexible, simple, and powerful, so a project with its own requirements can be built natively, without giving up part of the idea to match the tool.

Bring your own AI: the three ways to connect an assistant to a Birkly site

Rakete — Tue, 15 Sep 2026 09:28:00 +0000

Quick bit of context first, since this is a small project and there's a decent chance you're reading this without knowing what Birkly even is. Birkly is an open, AI-native content management platform that enables everyone to build, manage and operate digital experiences without vendor lock-in, unnecessary software complexity or dependency-heavy technology stacks. You can read more about it on https://birkly.io

Here's something I like about how Birkly handles AI: it treats an AI connection the same way it treats a person. You give it a role, and that role decides what it can and can't do. There's no looser, separate rulebook for "what an AI is allowed to touch." It goes through the exact same role and permission system a human user does.

That one choice shapes everything else. There are three different ways to connect an AI to a site: a personal connector, a service agent, and a built in assistant. Each one answers the same underlying question a bit differently, namely which role the AI is actually operating under. But no matter which of the three you use, admins still keep the final say. A site wide switch and a hard denylist sit above all three, all the time, and neither can be talked around.

Three ways to assign that role

Which role an AI connection ends up with, and where that role comes from, depends on which method you pick.

1. Personal connector: the AI acts as whoever's logged in

This is the default option. Under Settings → AI there's a single MCP URL for the whole site. You paste that into whatever AI client you're using, Claude, ChatGPT, Cursor, anything that speaks MCP, sign in with your Birkly account, and approve a consent screen that spells out exactly which role you're handing over.

From then on the AI simply has that account's permissions. If you're an Editor, it acts as an Editor. If you're an Admin, it acts as an Admin, full access to content, media, settings, plugins, the whole site. There's no separate "AI role" to think about, because there's no separate identity at all. It's just you, working through a different interface. One set of permissions to keep track of instead of two.

2. Service agent: a fixed role, not tied to a person

Sometimes "acts as whoever's logged in" isn't what you want. Maybe it's an automation, an integration, or a teammate who really doesn't need full account access just so their AI client can help with content. That's what a service agent is for. An admin creates it, gives it a fixed role that never changes (always Editor, say, no matter who's actually behind it), decides which people can even see it, and hands out its own dedicated MCP URL.

Under the hood it's the same tool registry and the same permission checks as the personal connector. The only real difference is where the role comes from. A personal connector's role follows the account. A service agent's role is pinned in place by an admin and stays put.

3. Built in assistant: bring your own model

The third option skips MCP entirely and lives right inside the admin panel as a chat window. You connect it with an API key from whatever provider you already use, OpenAI, Anthropic, Google, OpenRouter, a local Ollama setup, even a custom endpoint. You set its role the same way you would for a connector, and there's an optional "Require approval" setting that holds every write it proposes in an Approvals tab until a human actually clicks confirm.

This one's for people who just want a chat box in their CMS, backed by whichever model they already have access to, without setting up a separate AI app. Birkly genuinely doesn't care which company made the model. It only cares that it can call the same tool registry the other two methods use.

Same registry, three doors

What ties all three together is that they're not really three different feature sets. They're three different doors into the same room. Whether an AI is working through a person's own login, acting as a fixed role service bot, or chatting away in the admin panel on someone's own API key, it's reaching the exact same catalog of actions: content, media, the site's files, plugin admin tools, settings, all of it. The thing that changes between them is whose identity it's borrowing, and how a write actually gets confirmed. OAuth consent up front for the two MCP methods, an optional approval queue for the built in one.

"Bring your own AI" usually just means "point any model at our API." Here it stretches a bit further than that. You bring your own client, your own model provider, and your own identity story, personal, service, or built in, and the underlying permission model never has to bend to accommodate any of it.

A ceiling above all three

Borrowing a role, whether it's a person's own or a service agent's fixed one, is the identity layer. But it's not the only thing standing between an AI connection and something going wrong. Two site wide settings sit above all three methods, and they apply no matter which role is in play.

The first is the AI & MCP tools switch. It has three states. Normal, where tools simply follow role permissions and this is the default. Read only chat, where the built in assistant still works but no MCP tools get exposed or executed at all. And Disabled, where all tool execution is blocked outright and MCP's tools list comes back empty. This overrides whatever a connection's own approval setting says. If the site is set to Read only or Disabled, nothing gets more access than that, no matter how privileged its role is.

The second is the Plugin Security Denylist. Specific collections can be marked as protected, and specific plugin admin spaces can be denied entirely, which blocks that plugin's sidebar injection and any space scoped hooks it would otherwise get. Anything on this list is simply off limits to every plugin, regardless of what capabilities it's been granted elsewhere. The settings page describes it plainly as a hard barrier that can't be overridden.

So the role based model answers one question: whose permissions does this AI have. These two settings answer a different one entirely: what's the absolute ceiling, no matter whose permissions those are. Same doors as before, just with a breaker switch sitting above all of them that doesn't care which one an AI happened to walk through.