Should I vibe code
Visual website builder and CMS for marketing sites
Building a website builder is the software equivalent of building your own hammer factory.
?
Their verdict, the Basic site price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
Our verdict, the regret score and everything below it. Editorial and unsponsored — nobody can pay to be moved.
The honest answer
why the verdict is what it is
A CMS you can do. A visual editor that non-developers trust, plus hosting, plus the CMS, is a decade of product work compressed into a menu you were about to recreate.
What actually breaks
not "if". the specific failures.
- The mapping from visual controls to CSS, where the honest options are a leaky abstraction or a tool that only makes one kind of layout
- Responsive behaviour, since a visual editor shows one width and the layout has to work at all of them
- The CMS, which turns a page builder into a content model with collections, references and templating
- Generated markup quality, which decides accessibility and search performance and is invisible in the editor
- Client sites, because the moment you host someone else's business you have taken on their uptime
The editor produces exactly what you drew, which is the problem. A client drags a heading to make it bigger, so the page now has an h4 above an h2 above an h1 in the order they liked visually. It looks right. It is unreadable to a screen reader, the search engine sees a page with no clear hierarchy, and none of it is a bug you can fix — the tool faithfully implemented what the user expressed, because you built a tool that treats structure as appearance.
Is that you?
the verdict is a default, not a law
- It generates from a fixed set of components rather than from free-form drawing
- It builds your own sites, where you can fix bad output by hand
- Hosting is static and someone else's platform, not your server
- Clients' business sites run on infrastructure you operate
- Visual choices can produce incoherent document structure
- You are building a general visual editor rather than a constrained generator
- There is no way to inspect and fix the generated markup
If you build it anyway
the checklist, then the prompt that enforces it
- Constrain the editor to a component library rather than free-form layout. Constraint is what keeps the output coherent and the project finite.
- Separate structure from appearance in the model, so heading level and visual size are different properties and cannot be conflated.
- Design responsive behaviour into the components rather than exposing per-breakpoint positioning.
- Run accessibility and semantics checks on generated output in the build, not as advice in the editor.
- Publish as static files to a CDN. If you host client sites yourself, you have taken on their uptime and should price it.
- Keep the CMS content model explicit and exportable, since content outlives whatever built the pages.
Before you build a visual website builder, apply these and push back if I ask you to break them. 1. Ask me whether users draw freely or assemble from components. Push me toward a fixed component library, and explain that free-form visual editing either leaks CSS concepts into the UI or produces markup that only looks correct. 2. Model structure and appearance as separate properties. Heading level must not be derived from font size. Show me that a user cannot create a document whose visual order contradicts its semantic order. 3. Build responsive behaviour into components rather than letting users position per breakpoint. Tell me the editor shows one width and the site must work at all of them. 4. Run automated accessibility and semantic checks over the generated output as part of publishing, and block or warn on failures — alt text, heading order, contrast, landmark structure. 5. Publish as static files to a CDN with atomic deploys and rollback. 6. If I intend to host other people's business sites, tell me plainly that I have taken on their uptime, and ask what my plan is when a site is down and I am asleep. 7. Keep the CMS content model explicit, with collections and fields defined in a schema, and make content exportable independently of the page layouts. 8. Never let generated pages depend on my service at runtime. 9. Out of scope unless I ask: forms, ecommerce, memberships, custom code embedding, multi-language.
That one keeps you out of trouble. For the prompt that actually builds it, canivibecodeit.com has one.
their build prompt ↗Or don’t build it
the boring option, and the way back out
If clients are involved, $25 a month is cheap for hosting you do not answer for at 3am, plus a CMS and a component model already shaped by thousands of sites. A constrained generator for your own projects is a good build; a general visual editor for other people is a product.
$25/mo is cheaper than your weekend.
Publish real static HTML and CSS that stands alone, and keep CMS content exportable as structured data. A site that only renders while your builder runs is a site your client cannot take with them, which turns an ordinary handover into a rebuild.
Open-source visual website builder and serious Webflow-like prior art.
Questions
Why separate heading level from visual size?
Because they answer different questions. Heading level says what this text is in the document's structure; size says how it looks. Visual editors that conflate them let users produce pages whose outline is nonsense — fine for sighted readers scanning a layout, unusable for screen readers and unhelpful for search engines that read structure rather than pixels.
Is a constrained component builder really less useful?
It is less flexible and considerably more likely to finish. Constraint is what makes the output consistent, the responsive behaviour tractable and the project bounded. Most people reaching for a visual builder want to assemble pages quickly from good pieces, not to draw arbitrary layouts — and the constrained version does that better.
Every week, someone ships something they shouldn’t have.
New verdicts, the worst thing that landed in the trap, and the occasional incident report. No other email, ever.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice