We are Birkly & Other Things, a small studio in Denmark. We design and build websites. We also develop Birkly, the open-source CMS those sites run on.
That second part sounds like a footnote. For us it is the whole business model. It is why we like the work, why we can move fast without trapping clients in someone else's funnel, and why we can publish opening prices that would be hard to defend if we were reselling platforms and padding every quote.
To celebrate opening the studio, every project we start in our first six months gets a heavily discounted price. The craft does not change. The stack does not change. What changes is that we are hungry for case studies, feedback, and proof that the way we build scales beyond our own sites. The product site at birkly.io is one example. Our own studio site is another. Kekaba shows the same stack on a portfolio and journal.
This post is not a sales page. It is how we think, written for developers and technical founders who wonder whether "studio plus CMS plus AI" is hype or a coherent workflow.
What clients actually buy from us is not a generated layout. It is custom design, a plan for content and structure, and a site architecture that fits how their business works. The opening offer on our site still says custom design, no templates. That is the line we mean.
The studio advantage is architectural, not magical
Most client projects die in the gap between what the business needs and what the product allows.
Page builders give you speed until you need a content model that does not exist. Enterprise CMSs give you power until you need hosting in a specific country, an exportable backup, or a template that does not fight your brand. SaaS stacks give you convenience until the monthly bill and the feature gate become the project manager.
We picked a different default. Birkly is file-based PHP with no mandatory database, self-hosted where you want it. The product pages spell out the no runtime dependencies angle plainly: no npm or composer chain to babysit. Collections and entries live in plain project files. The public site is HTML and CSS you can read. The admin is decoupled from the core so we can redesign UI without rewiring business logic.
For the studio, that means we choose hosting (our VPS, the client's infra, EU-only if that matters). We choose how data is stored and backed up: Git-friendly content, portable exports, no opaque vendor vault. We build to the client's shape through digital design, not a theme marketplace's idea of "industry."
Flexibility is not "we can do anything." It is "we are not forced through a single funnel of pages, fields, and integrations."
Design and structure before templates
Every project starts with a conversation: what the business does, who visits the site, what they should do next. From that we sketch structure (pages, sections, repeating content) and an information architecture that matches the client, not a vertical SaaS preset.
An experienced designer directs that work. You see clickable design before heavy build work. Typography, spacing, rhythm, and how the brand should feel are human decisions. We are not shipping a template pack with your logo on top. We are not asking a model to "make me a modern website" and calling it done.
AI can help with drafts: placeholder copy, rough markup, filling repetitive fields. It does not choose the concept. When something looks like generic AI layout or template churn, we throw it out and redraw. The site should look like one business, not like every other landing page from the same month.
Only after the plan and design are agreed do we lock the Birkly content model and build. That order is why our process has a clear design phase before launch. The CMS stays flexible. The design intent does not get lost inside a theme setting.
AI speeds us up. It does not run the show.
We use AI heavily in the CMS, in our agents, and when drafting content or scaffolding projects. We are not ashamed of that. We are careful about where it is allowed to touch production.
Our rule is simple: people with taste and context act as directors. AI proposes. Humans approve, edit, or throw away. On the product side, Birkly is built for humans and agents in the same instance: structured APIs, Agent Guide, connections your team can approve. Suggestions can stay drafts, approvals exist, and nothing has to go live because a model was confident.
What that looks like in practice:
- Plan and design first (see above). Then content model. What repeats? What is shared chrome? What do visitors submit? We define collections and fields to match the agreed structure, not the other way around. Birkly's own explainer walks through collections, entries, and templates in three steps if you want the parallel product view.
- Templates second. List pages, detail pages, static marketing sections, wired with Birkly's client templating and
birkly-client.js, not a proprietary shortcode dialect. - AI as accelerant. First drafts of copy, starter HTML, bulk entries, repetitive refactors. All inspectable in Git.
- Human override everywhere. If a template is wrong, we edit the file. If the schema is wrong, we migrate the collection. If a plugin boundary is wrong, we patch the extension or build a small one.
That last point is rarer than it should be in "AI website" shops. We can step into every layer of the build: admin, API behaviour, project/ templates, plugins, deployment. We are not locked into a no-code surface that hides the system.
Connected agents (for example via MCP) can create collections, write project files, and seed content. The same paths are open to a developer with a text editor. No parallel universe.
Dogfooding is an economic advantage, not just a slogan
We do not license a CMS per client seat. We do not pay a platform tax on every project and pass it through as agency markup. We maintain the runtime we ship.
Reuse matters. Starter patterns, templates, and plugin combinations are already battle-tested from previous work. The person who answers mail knows the CMS kernel, not a helpdesk script. When something hurts in a client project, it often becomes a product fix, and everyone's sites benefit. Ops stay lean: no database cluster for a brochure site, sensible hosting without enterprise bloat.
So when we publish reference pricing (websites from 15,000 DKK, hosting and support from 190 DKK per month), that is not loss-leading mystery meat. It is a reference point for a custom-designed Birkly build with clear scope. Every project still gets a quote before we start. Content volume, integrations like Commerce, Events, Members, or Automation, and timelines move the number.
The opening discount is honest too: limited window, same deliverables, we gain portfolio and product feedback. We say that out loud on the offer section of the studio site. Dev.to readers can smell hidden upsells. We would rather be boring and precise.
What "built on Birkly" actually means for a client
Non-technical owners hear "CMS" and think WordPress clutter or Squarespace limits. We pitch three promises, and we try to say them the same way on birkly.io and on our services page.
First, shape it around the business. Products, team, events, journal posts: fields match how they talk, not how a template vendor talks.
Second, they can run day-to-day content. If you can write email, you can publish. No developer for every text tweak.
Third, they own the result. Design, content, and deployment are portable. "Yours to keep" is not legal fine print. It is the architecture.
When the business outgrows the launch scope, we add plugins, not a platform migration. The studio lists what we ship and extend. The product site describes the Hub catalog for Commerce, Events, Automation, Studio, and the rest. Each plugin is self-contained. We do not fork the core for one client's whim.
For developers reading this: Birkly is open source and still in early alpha. birkly.io does not hide that tone. We build production sites on it because we control the risk, not because we pretend semver serenity. If you self-host, you get the same separation of concerns we rely on: core, admin presentation, client delivery, extensions.
Who this is for
We work with people who want a site that looks and works like their business, planned and designed for them, not scraped from a template catalog or a one-shot AI prompt.
That includes anyone who wants a designer in the loop from the first conversation through launch: structure, visual direction, and build in one studio. It includes regular company sites, portfolios, journals, and case-driven work like what we have already shipped. It includes shops, events, sign-ups, and member areas when Commerce, Events, or User plugins fit the model you already agreed in design.
It includes owners who will update content themselves and founders who care about hosting and data. It includes teams that want digital design and development together, plus optional hosting and care. It includes odd workflows, custom plugins, redesigns, and migrations onto Birkly when the old site never matched how you work.
Most projects mix those things. If you want custom architecture and a directed design process, that is the default for us, not an upgrade tier. Say hej on the studio site and we figure out scope from there.
Why we wrote this on DEV
We hang out here because the argument matters to this audience. You can use modern AI without giving up the repo. You can run a studio without becoming a reseller. You can open-source the middle layer and still make a living on design, implementation, and care.
If you are building your own stack, read birkly.io, download the CMS, or ignore us and steal the workflow: content model first, decoupled UI, human gates on AI.
If you need a studio hand for the first build, the opening offer on birklyandotherthings.com is live for our first six months. Bring a weird content model. We like those.
