If you set out to build a content management system today, the first job is not code. It’s reading. Every established platform has spent years getting one or two things right, and the people who use them will tell you what those things are. So before we built Bernard, we went through the market platform by platform and wrote down what each one does well. Then we asked a second question: if an AI is going to do most of the editing, does that feature still look the same, or does it need building another way? This post is that list, what we chose not to copy, and how we built the parts we kept. I’m biased, since I built it, and I’ll say where it still falls short.
The review: what each platform gets right
WordPress: you own it
WordPress is open source. You can run it on any host, read every line of it, and take the whole thing with you when you leave. Its export tool writes a WXR file holding your posts, pages, custom post types, comments, custom fields, taxonomies and users. Nobody can switch off a feature you rely on.
Then there’s the plugin market. Whatever you need, someone has probably built it, and a business can bolt on a shop, a booking system or a membership area without hiring anyone.
It also got permissions right a long time ago. The WordPress docs describe a Contributor as “somebody who can write and manage their own posts but cannot publish them.” Remember that role. It comes back later.
Squarespace: it all looks like one thing
A Squarespace site looks finished. The fonts, spacing, colours and image treatment are chosen together, so a non-designer can’t easily make a page that clashes with the rest of the site. That coherence is the product. Most small business owners don’t want design freedom. They want the site to look as if one careful person made it.
Wix: put anything anywhere
Wix lets you drag an element to any spot on the page and leave it there. For someone who thinks visually, that’s the most natural editor on the market. You don’t have to learn what a container or a column is.
Webflow: clean markup and real content types
Webflow is built for designers who know how the web works. It writes cleaner HTML and CSS than most visual builders. Its CMS collections let you define a content type (a team member, a case study, a recipe) with typed fields, then design one template that renders every item. That’s how a developer would model content, offered to people who don’t write code.
Shopify: commerce done properly
Shopify is a checkout first and a website second. Products, variants, stock, tax, shipping, orders and payments are all first-class.
HubSpot: one record per person
HubSpot’s core idea is that every person you deal with has one record. The form they filled in, the emails they opened, the deal they’re part of and the notes your team left all hang off that record.
Kit, Ghost and the newsletter tools: the list is the asset
Kit (once ConvertKit) and Ghost treat the mailing list as the thing that matters. Writing goes out by email first, and the subscriber relationship belongs to the writer. For many independents the list is worth more than the website. A good CMS should treat it that way.
What we chose to leave behind
Every one of those strengths comes with a cost. Here is what we didn’t copy.
Plugin sprawl. The WordPress plugin market is a strength until you own a site with thirty plugins from thirty authors. Each one needs updating, any one can break another, and a forgotten one is a common way in for attackers.
Lock-in. Wix’s own help centre says your site “needs to be hosted and operated on Wix’s servers,” because the platform “uses Wix’s proprietary technology”. The content is yours, but the working site can’t move. Squarespace’s export says “many features rely on our platform’s JavaScript and CSS, so some content doesn’t export.” We wanted an owner to be able to leave with their words, images, pages and contacts.
Per-seat pricing. HubSpot prices by the seat: every person who logs in costs the same again. That suits a sales team. It doesn’t suit a shop with one owner and a part-timer. We price by what the site does, not by how many people use it.
SEO added afterwards. On most platforms, search basics (titles, descriptions, structured data, sitemaps, image text) arrive as a plugin, a checklist or a paid app. They depend on the owner remembering. We wanted them checked every time, without asking.
The page editor as the only way in. Every platform above assumes a person will sit in front of an editing screen. That was the right assumption for twenty years. It isn’t now. An assistant like Claude or ChatGPT doesn’t need a canvas. It needs a clear way to read the site, a small set of precise tools to change it, and a gate in front of anything going live.
Starting from scratch: each kept feature, rebuilt for an AI editor
Ownership, rebuilt as plain files with a history
Each Bernard site is kept as plain files with a full history, in two copies: the draft that the owner and the assistant work on, and the published site. What visitors get is static pages, so there is no PHP and no plugin layer on the live site. Every change has an author and a timestamp. The owner can restore any of the last 100 published versions.
That gives us much of WordPress’s ownership without its upkeep. When an owner leaves, they take their words, images and pages, plus their domain, and they can download their contacts as a spreadsheet that records who can be emailed and why.
Structured content, rebuilt as data the assistant can address
Webflow’s lesson is that content should have a shape. For an AI editor that matters more than ever. A person points at what they want changed. An assistant has to name it, and “the second paragraph under the pricing heading” only works if the system can resolve it to one thing every time.
So the parts of a site that are really data are stored as data. Shop, course, lesson and membership pages are built from records (a product with variants and stock, a course with lessons) and rebuilt when the records change. The assistant edits the record, not the HTML.
The rest of the site is ordinary pages the owner can edit freely, and there the trick is stable handles. Each element carries a key, so a tool can say “set the text of this element” rather than “rewrite this page”.
Every AI action, rebuilt as one tool definition
The worst pattern in AI editing is the one every first attempt reaches for: read the whole page, rewrite the whole page, save it. It’s slow, it’s wasteful, and it quietly drops things the model didn’t think mattered.
Our answer is one list of tools, each defined once. The same tools are offered to whichever assistant the owner connects (Claude, ChatGPT or Gemini) and to our own assistant inside the app, so the two can’t drift apart. Security sits in the tool, not the prompt: every call checks that the site belongs to the person asking before it touches anything.
The tools are small and specific. Find elements, set one element’s text, change one CSS declaration, swap one image, set a page’s meta description. There’s a check that shows what a change would do before anything is saved. Each call either does one checkable thing or fails loudly.
Permissions, rebuilt as draft-only edits
This is where the WordPress Contributor role comes back. The assistant gets that role: it can write, and it can’t publish. Every edit lands on the draft. The owner sees a preview of the real page, a plain-English note for each change, and can tick or untick each one before approving. Bernard’s own assistant in the dashboard has no publish button at all. A connected assistant is instructed never to publish on its own, and does so only when the owner asks. Some actions an assistant never takes on its own whatever the setting: prices, deleting anything, and who can get into the site.
The approval step had to work for someone who will never read a diff. The owner of a pottery studio looks at the page on her phone and decides whether it looks right. The version history does the bookkeeping underneath. She never sees it.
SEO, rebuilt as checks on every publish
Instead of a checklist, every publish re-reads the live site and runs four checks: broken links, page titles and descriptions, structured data, and Google’s speed test on mobile and desktop separately. The sitemap refreshes and search engines are told about the change. When a site moves in, we add image alt text, repair structured data, recompress images and strip unused CSS as part of the move. An accessibility test runs once a week in a real browser, so the audit doesn’t go out of date.
Reports, rebuilt as a note with a button
Every platform above gives the owner a dashboard, and most owners never open it. Measuring is on from the start. Each Monday Bernard reads the site’s numbers and writes a few plain sentences, with at most three suggestions. Each one has a button that does the work on the draft, and the next week’s note says whether it worked. Reports also count the visits AI assistants make to read the site, checked against the lists the AI companies publish. On the Medium and Large plans Bernard also plans the marketing every six weeks and drafts the posts, emails and pages.
One record per contact, rebuilt next to the site
HubSpot’s idea, without the seats. Contacts, forms, email campaigns and automatic emails live in the same platform as the site. A form on a page writes to the contact book. The same record decides who a campaign can reach, so the consent status you see is the one the sender uses. Owners can add their own fields to a contact by asking in plain words, and changes to many contacts at once wait for approval.
Design coherence, rebuilt from the owner’s own look
We don’t offer a template gallery. A moved site keeps its own look, and new pages start from it. A business with no site starts from an interview about what it does, and Bernard drafts the first homepage from the answers. For visual work we lean on Claude Design: an owner can design a page there, see it and change it, then send it to their draft one page at a time. Emails can be designed the same way. It isn’t Wix’s free canvas. Drag is limited to putting things in a new order: sections, gallery photos and product cards, on a computer.
Room to grow, rebuilt as switches
Squarespace and Wix bill each site separately, and so does Webflow. On Bernard every plan covers one site, and another site is an add-on the owner switches on in the app, on the same payment. A shop and courses are switches too.
Your own AI, on any plan
An owner can connect their own Claude, ChatGPT or Gemini account on any plan. Editing through it costs them nothing extra from us. It also keeps the assistant portable. MCP, which describes itself as “an open-source standard for connecting AI applications to external systems,” means the owner isn’t locked into our choice of model.
The owner’s own code, rebuilt as approved bytes
This is the part I’d most like other builders to think about. WordPress has a capability called unfiltered_html, which “allows user to post HTML markup or even JavaScript code in pages, posts, comments and widgets.” Administrators and Editors hold it on a single-site install.
Put an assistant in that seat. It reads things: the owner’s old site, a supplier’s page, a pasted email. Any of them can carry instructions aimed at the model. If the model can write a <script> tag into a live page, a prompt injection becomes a stored script on a real business’s site, running in every visitor’s browser.
So JavaScript an assistant types into a page is stripped. Code runs on a Bernard site four ways: Bernard’s own interactive behaviours; libraries from a vetted list, each pinned to a version; tracking tags from a fixed list; and the owner’s own code. That last lane takes a proposed script, checks it, and puts the exact bytes into the draft with a plain-English note on what it does for visitors. It runs only once the owner publishes. The rule we hold ourselves to is “no code runs on your site that you did not approve.”
What is still hard
We’re newer and smaller. WordPress has a two-decade head start, an enormous plugin library and a whole hosting market. Shopify has years of commerce edge cases behind it. We don’t.
Drag is limited. If you think in Wix’s terms, Bernard will feel stiff. The header, menu and footer stay where they are, and on a phone you can’t drag at all.
The code lane is on for everyone. Every owner can now bring their own code. It still passes the same checks, and it goes live only when the owner publishes.
The CRM is light. Companies have a stage list, but there are no deals with values attached. A business with a sales team and a real pipeline needs more, and for a team like that we put together enterprise packages with Sasha, priced on a call.
The speed gain is modest. We measured ten live sites before and after moving them, in August 2026. The average mobile Lighthouse score went from 65 to 72. Seven sites improved. Two that were already fast got slower: one from 91 to 78, one from 72 to 67. That’s the only figure we publish, because it’s the only one we’ve measured properly.
If you’re choosing, not building
Most people reading this aren’t about to build a CMS. If you’re choosing one for a small business, Spencer has written the plain-English version, with prices in pounds: the best website builder for a small business. It doesn’t crown a winner. Our friends at Context is Everything have also written about how website builder rankings are made, and who gets paid when you click.