Yesterday I wrote about what Antsand is, why I kept building it for fourteen years, and where I want to take it. The obvious follow-up question is simpler: why did I build any of this when WordPress, Webflow, Ghost, Substack, and a growing number of AI website builders already exist?

The honest answer is not that Antsand is better than all of them. In several areas it is clearly worse. WordPress has an ecosystem Antsand may never have. Webflow has a much better visual design experience. Ghost and Substack can take a writer from a blank page to newsletters, memberships, payments, analytics, and audience growth far more quickly than I can.

Antsand survived because I kept needing a different contract. I did not only want to publish a page inside a platform. I wanted to describe a complete website as structured data, compile that description into a self-contained application, deploy it to a server I control, connect forms and operational records, and let scripts or AI tools make reviewable changes through the same API. That requirement makes Antsand harder to explain, but it is also the reason I still use it every day.

These Products Are Not Really One Category

Calling all of these products a CMS hides the most important differences. A CMS stores and edits content, but each product surrounds that core with a different business and runtime model.

• WordPress is an open-source application platform with themes, plugins, content types, users, and a large hosting ecosystem.
• Webflow combines visual website design with structured CMS collections and managed hosting.
• Ghost is an open-source publishing system centred on publications, memberships, newsletters, and subscriptions.
• Substack is a hosted publishing and distribution network centred on writers, subscribers, email, payments, and discovery.
• Modern hosted builders optimize for getting a visually credible website online quickly, increasingly through prompts and generated sections.
• Antsand is my structured content, application-generation, and federated deployment system.

Once these contracts are separated, the comparison becomes more useful. The question is not “Which CMS has the most features?” It is “Which part of the system do I want the platform to own?”

The Comparison I Actually Care About

This table is not a scorecard. “Managed hosting” can be an advantage because someone else handles updates, backups, security, email delivery, and scaling. “Owned runtime” can be an advantage when a system must survive independently of the builder. The correct answer depends on which burden you are prepared to carry.

WordPress Offers Ownership, But Its Plugin Model Has A Cost

It would be inaccurate to describe WordPress as a closed platform that traps content. WordPress is open source and explicitly designed around data ownership, can be self-hosted, supports custom post types, taxonomies, metadata, themes, and plugins, and explicitly emphasizes data ownership. Its REST API lets external programs read and modify posts, pages, taxonomies, and other resources. WordPress solves a great deal out of the box, and its ecosystem makes it easy to find an extension or a developer for almost any conventional website requirement.

That ecosystem is also why I would not choose WordPress for my own client work. A customized installation can spread behavior across core, a theme, child-theme overrides, plugins, custom plugins, database state, page-builder metadata, and hosting configuration. Every additional plugin introduces another release cycle, compatibility boundary, update decision, and piece of executable code that must be trusted. A plugin can be abandoned, conflict with another plugin, break after an upgrade, or add a security problem to a site that previously worked.

These were not theoretical objections added after Antsand existed. They were part of why I started building Antsand. I wanted the website architecture, content structure, styling contracts, forms, data, and deployment process to be understandable as one system rather than assembled from a changing collection of third-party extensions.

Antsand therefore takes the opposite approach. I do not install a plugin to teach one site a new architecture. I extend the shared module, section, compiler, or data contract and then regenerate the affected sites. That gives me a much smaller ecosystem, but the behavior I depend on remains inside one codebase and one deployment pipeline.

Webflow And Antsand Start With Different Design Models

Webflow’s strength is that a designer can build responsive layouts visually and connect those layouts to structured CMS Collections. Its official CMS documentation describes collections, items, fields, collection lists, and generated collection pages. That is real structured content, not merely drawing boxes on a canvas.

Antsand starts from a different observation. Take almost any section from a normal website and it can usually be described as a header, a body, and a footer. The header establishes what the section is about. The body contains its rows, cards, media, data, or controls. The footer carries the next action or supporting information. Antsand makes that recurring structure an explicit design contract instead of treating every section as a free-form canvas.

A Databoard stores those sections alongside their routes, content, CSS class maps, settings, behavior, and API data. Sass v2 supplies a reusable design vocabulary, while site-specific classes can extend it. The header/body/footer structure remains stable, but changing its content and class map can produce very different visual results. The compiler then turns that structured description into the application.

This is not always as immediately intuitive to a person as dragging elements around a visual canvas. I understand the section hierarchy because I designed it and have used it for years. What has changed is that AI agents also understand the hierarchy surprisingly well. They can inspect a section contract, find the appropriate Sass v2 classes, change the content or presentation map, validate the result, and submit a narrow patch without inventing an entirely new page structure.

Webflow is still easier when the primary job is direct visual composition. Antsand is useful when design needs to remain structured, reusable, API-addressable, and compilable across independently deployed websites. Its design system is not an unfinished version of Webflow’s designer. It is a different way of representing a website: closer to how the final HTML, CSS, and application sections are assembled, and increasingly suited to AI-assisted production.

Webflow also supports exporting CMS collection content as CSV. That is meaningful portability. Antsand’s portability target is different: the compiled website directory itself is the deployment artifact. The public server does not call Antsand to render each request.

Ghost And Substack Are Better Publication Products

Ghost is probably the strongest alternative if the goal is an independent publication with a clean editor, memberships, paid tiers, newsletters, analytics, themes, and APIs. Ghost can be self-hosted, while Ghost(Pro) offers the managed version. Its public Content API supports headless delivery, and its managed plans include publication and membership infrastructure that Antsand would have to build and operate separately.

Substack goes further toward distribution. Its publisher workflow combines publishing with email delivery, subscriber management, paid subscriptions, recommendations, network discovery, engagement metrics, and an existing reader graph. It also lets publishers export posts, subscriber lists, and related statistics. If the main problem is finding and monetizing readers, Antsand is not competing with that network.

ShivasNotes exists for a different reason. I use it as a public engineering memory system connected to source code, experiments, SVGs, carousels, APIs, and generated sites. Audience growth matters, but it is not the only contract. I need the publishing record to remain connected to the engineering workflow that produced it.

Hosted And AI Website Builders Optimize For The First Mile

The newest website builders can produce a polished landing page from a prompt in minutes. That is a genuine improvement. AI is increasingly good at layout, copy, icons, illustrations, and responsive components. For validating an idea, this can be dramatically faster than designing a platform schema.

The difficult part begins after the first page: Where do forms go? How are records permissioned? How are several brands updated together? Can one change be previewed, validated, compiled, deployed, and rolled through multiple sites? What artifact remains if the builder disappears? How does an AI agent know whether it is changing content, presentation, routing, permissions, or application logic?

Antsand is optimized for that second mile. Its AI workflow is deliberately less magical. An agent can inspect the board contract, fetch brand guidance, prepare a patch, dry-run it, apply it through an authenticated API, compile Sass, regenerate the site, and verify the result locally. The agent is not asked to rediscover the application architecture from a screenshot on every run.

What Antsand Actually Compiles

The word “compile” can sound like marketing when applied to a website builder, so here is the actual path. A Databoard records the website structure and the inputs needed to generate it:

Databoard
  pages and routes
  sections: header + body + footer
  content and CSS class maps
  Sass, menus, settings, API data
        |
        v
validate -> compile Sass -> generate HMVC
        |
        v
router.php + controllers + actions
Volt views + compiled CSS + data snapshot
site-owned SQLite records where required
        |
        v
standalone nginx + PHP website

At runtime, the generated site needs nginx, PHP, its generated application files, and its own data. It does not need a live request back to the Antsand builder. Antsand matters when the site is being organized, validated, compiled, and deployed. The artifact matters when a visitor opens the page.

This is the same broad engineering preference I use in C-Kernel-Engine: make the control structure explicit, compile ahead of time, ship an inspectable artifact, and keep the runtime as small as the problem allows. Antsand and CKE are different products, but they share that design instinct.

Where Antsand Is Clearly Weaker

Owning the compiler does not erase product gaps. Antsand currently asks too much of its user and too much of me as its operator.

• Onboarding: a new user cannot sign up and understand the complete system in ten minutes.
• Visual design: Databoard is not as immediate or polished as Webflow’s visual canvas.
• Ecosystem: there is no WordPress-sized library of themes, plugins, agencies, and tutorials.
• Distribution: there is no Substack reader network or built-in growth engine.
• Publication operations: Ghost provides a more complete newsletter and membership product.
• Documentation: many Antsand contracts are only now becoming clear enough for another person or agent to use safely.
• Bus factor: Antsand is still primarily built and operated by one person.

These are not minor caveats. They explain why I would not recommend Antsand as a universal replacement for an established CMS. The platform has to earn its complexity through the workflows it uniquely enables.

Which Platform Should You Choose?

• Choose WordPress when you need a flexible, owned, widely supported website platform.
• Choose Webflow when visual design and a polished marketing workflow are the centre of the job.
• Choose Ghost when you want an independent publication, newsletter, memberships, and subscriptions.
• Choose Substack when audience distribution and the reader network matter more than application control.
• Choose a hosted or AI builder when speed to a credible first site is the primary constraint.
• Consider Antsand when content, application structure, data, multiple sites, API automation, and owned deployment must behave as one system.

Why I Am Still Building Antsand

Antsand is not the shortest route to a blog. If that were the requirement, I should have stopped years ago. It remains useful because my work keeps crossing boundaries that conventional publishing products intentionally keep separate: technical articles, structured data, forms, assets, company websites, local previews, federated deployments, AI-assisted editing, and eventually governed data workflows for robotics and CPU AI research.

The mainstream platforms in this comparison have taught me a lot. WordPress proves the value of openness and ecosystem. Webflow proves that design tools can make structured content approachable. Ghost proves that an open publication product can still be focused and polished. Substack proves that distribution is itself a product. AI builders prove that the first draft of a website can be dramatically cheaper than it used to be.

Antsand’s job is not to pretend those strengths do not exist. Its job is to make my own narrower bet work: organize the system as data, compile the public application, keep the artifact owned, and make every automated change reviewable. If that contract becomes useful to other builders over time, then Antsand may grow beyond the platform I originally built for myself.