Should I vibe code
Create a simple responsive landing site from text-first blocks and publish it
A text-first site builder is a static site generator with a nicer front door. You already own three of those.
?
Their verdict, the Launch price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-04.
?
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
This one is closer to worth building than most things in the category, because the input is text and the output is HTML, and everything in between is a problem you have already solved at least twice. Where it stops being enjoyable is the unglamorous half: attaching a custom domain, provisioning and renewing certificates, writing redirects when you rename a page, and keeping the published site up while the editor is broken. Typedream itself makes the point neatly — it now belongs to beehiiv, which is the platform risk everybody warns about and also the exact reason to aim for an exportable static site rather than a runtime. Build the editor if you want it. Do not build the hosting.
What actually breaks
not "if". the specific failures.
- Custom domains: DNS, certificate issuance and renewal, the apex-versus-www decision, and the ACME failure that surfaces as a browser warning rather than an alert
- URLs. Rename a page in a WYSIWYG and the old link dies unless something wrote a redirect, and the old link is in a newsletter you already sent
- The editor and the site sharing one deployment, so a bug in the editing UI takes the live page with it
- Rich text edge cases — pasting from Google Docs, nested lists, an image inside a link — which is where every text-first builder actually spends its engineering budget
- The SEO basics nobody demos: canonical tags, a sitemap, an OG image, and a page whose title is not 'Untitled'
- Preview. As soon as somebody who is not you publishes, they need to see it before the world does, and preview is a second rendering path to keep honest
Is that you?
the verdict is a default, not a law
- It publishes plain static files you could serve from any bucket tomorrow
- You are the only author and the site is your own
- You would be perfectly happy editing Markdown and the editor is purely comfort
- You are also building the hosting, the certificate renewal and the domain attachment
- Somebody non-technical publishes to it and expects a preview and an undo
- It is a live campaign target where an hour of downtime costs signups
- You are selling digital products through it, which is a payments product wearing a landing page
If you build it anyway
the checklist, then the prompt that enforces it
- Separate the editor from the runtime completely. Publishing emits static files; serving those files must not depend on any code you are still changing.
- Keep a redirect map as first-class content. Every slug change appends an entry, and nothing ever removes one, because someone else's link outlives your rename.
- Make export the default rather than a feature: content in files, files in git, and a build you could run without the editor at all.
- Put the boring metadata in the model — title, description, canonical, OG image, sitemap — and refuse to publish without them.
- Test the paste path early with real content from Google Docs and Notion. That is where the rich text model either survives or collapses.
- Automate certificates and alert on renewal failure. A padlock that lapsed on a Friday is the most common way a small site goes visibly wrong.
I am building a text-first website builder that publishes landing pages. The editor is the easy part. Order the work so the publishing and hosting behaviour is right before the writing experience is nice.
1. Content lives as portable files — Markdown or a documented JSON block
format — in a directory I can commit to git. The database is a cache of
those files, never the only copy.
2. Publishing produces static output that a plain object store can serve. The
editor must not be on the request path for any live page, so that an editor
bug cannot take the site offline.
3. Build the redirect map before the second page exists. Renaming a slug
appends a permanent redirect and never silently breaks the old URL. Nothing
in the UI may delete a redirect.
4. Enforce page metadata at publish time: title, meta description, canonical
URL, OG image, and a generated sitemap. Refuse to publish a page still
called Untitled, and explain why rather than warning once.
5. Certificate provisioning and renewal is automated, and renewal failure
raises an alert I will actually see. Do not treat TLS as setup work that
happens once.
6. Implement preview as a real, separate rendered path that shows exactly what
publish would produce. Do not fake it by rendering the editor canvas.
7. Every publish is a numbered revision with a one-action rollback. Show me
the diff of what changed since the last publish before it goes out.
8. Exercise the paste path deliberately: content from Google Docs and Notion,
nested lists, images inside links, and smart quotes. Sanitise pasted HTML
to an allowlist rather than storing whatever the clipboard contained.
9. Process images at publish — responsive sizes, modern format, explicit
dimensions — and never ship an original camera file to a visitor.
10. Out of scope, and say so rather than half-building it: selling digital
products, payments, memberships, and multi-tenant hosting for other
people's sites. If I ask for any of those, tell me it is a different
product with a different risk profile.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 the site is a live marketing asset and somebody other than you edits it, twenty dollars a month is a bargain for domains, certificates, previews and a rollback button that already works. The honest counter-argument is that a static generator plus a git-backed CMS gets you most of the way for nothing — which is exactly why this is DEMO ONLY rather than YOUR FUNERAL. Nobody gets hurt; you just end up maintaining a worse Netlify.
$20/mo is cheaper than your weekend.
If content is files and publishing is static output, there is barely an exit to plan — point a different generator at the same directory and rebuild. That is the whole reason to insist on it early. The parts that will not follow you are the redirect map and any form submissions, so keep both in plain, dumpable formats from the start.
Open-source visual website builder built around web standards rather than a proprietary page format.
Embeddable open-source visual editor for React, if you want the editing surface without writing one.
Questions
Typedream got acquired. Does that strengthen or weaken the case for building my own?
Both, and the resolution is the same either way. Acquisitions are why people build their own tools, and they are also why the thing you build should emit static files you could serve without it. If your builder produces a folder of HTML, a vendor disappearing is an afternoon. If it produces rows in a database only your renderer understands, you have recreated the problem you were avoiding.
Why is the hosting the hard part rather than the editor?
Because the editor fails in front of you and hosting fails in front of everyone else. A broken toolbar is annoying; an expired certificate is a full-page browser warning on the URL in your email signature, discovered by a stranger. Domains, TLS and redirects are the parts with no demo value and all of the operational weight.
Is there a version of this that is genuinely SHIP IT?
Yes: a static site generator with a small editing UI on top, publishing to a host somebody else runs. Keep the content in files, let a platform handle domains and certificates, and you have removed every item from the maintenance list while keeping the part you wanted to build.
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.
Tilda ships 550 blocks that survive a 320-pixel phone. Your agent will build the editor and nine blocks.
One page, one deploy. You do not need a builder to build one page.
You don't want a website builder. You want one page. Those two things are about three months apart.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice