Should I vibe code
Assemble a responsive landing site from a curated block library and export it
Tilda ships 550 blocks that survive a 320-pixel phone. Your agent will build the editor and nine blocks.
?
Their verdict, the Personal 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
The editor is not the product. Tilda's asset is five hundred and fifty blocks that somebody has already made behave on a 320-pixel phone, in Safari, with a headline the client typed too long. An agent will hand you a drag-and-drop canvas, a JSON page schema and a publish button inside two days, and the demo will look convincing because you will fill it with the three blocks you built. The gap opens on the fourth page, when you need a pricing table, a testimonial row and a footer that does not collapse, and each one turns out to be a small responsive design problem with your name on it. Add the built-in form receiver — a public write endpoint wired to your inbox — and a weekend project has quietly become a thing you maintain for as long as the site exists.
What actually breaks
not "if". the specific failures.
- Responsive behaviour, one block at a time. Each block is its own breakpoint problem, and you will find them individually, on other people's phones, after publishing
- The form endpoint, which is public by definition and will collect spam long before it collects a lead — and which, unlike the rest of the builder, holds strangers' personal data
- Image handling. Tilda resizes, converts and serves through a CDN; a hand-rolled builder cheerfully publishes the 4MB photo somebody dragged in
- The page schema, the first time you rename a field and every saved page silently loses that section
- Custom domains and certificate renewal, invisible right up until the morning the padlock disappears and the site reads 'not secure'
- Editing by anyone who is not you. The moment a colleague touches it, autosave, undo and version history stop being optional and start being the reason they call
Is that you?
the verdict is a default, not a law
- The site is yours, it is a handful of pages, and you are the only person who edits it
- You would otherwise be hand-writing HTML and the builder is a convenience for exactly one user
- Nothing on it collects anything from strangers
- You are building it so a client can edit their own site — congratulations, you are now their CMS vendor
- The forms feed a pipeline and a dropped submission costs a deal
- The site is how the business gets found and a bad publish takes it off the internet
- You have not decided what happens to form submissions after ninety days
If you build it anyway
the checklist, then the prompt that enforces it
- Store pages as versioned JSON with an explicit schema version, and write the migration before you rename a field. A builder without page history loses work, not layout.
- Publish to static files behind a CDN rather than rendering from the editor's database, so the editing path and the serving path can fail independently.
- Treat the form endpoint as hostile from the first commit: rate limits, a turnstile or honeypot, size caps, and never echo a submission back into a rendered page.
- Every submission is somebody's personal data. Decide the retention window and build the deletion path before the first form goes live, not after the first request.
- Automate images at publish time — resize, convert, set explicit width and height. Manual asset discipline is how builder sites end up at four megabytes.
- Build static export before you build the twentieth block. A folder of HTML you can serve anywhere is the difference between a project and a trap.
I am building a block-based website builder for my own landing pages. The editor is the fun part and the least important; order the work so the parts that lose data or leak data come first.
1. Build static export before anything else. At any moment I must be able to
dump a self-contained folder of HTML, CSS and images that serves correctly
from any static host with no runtime of yours involved.
2. Pages are versioned JSON with an explicit schema version, every save is a
new revision, and restoring a previous revision is one action. Never
overwrite in place.
3. Any change to a block's field names ships with a migration for existing
pages plus a test that loads a page written against the old schema. Losing
a section on rename is the failure I care most about.
4. Publishing writes static files to a CDN or object store. The editor
application must never be on the request path for a live page, so an editor
outage cannot take the site down.
5. Before the first form block exists, build the submission endpoint properly:
per-IP and per-form rate limits, a size cap, a bot challenge, no reflection
of submitted content into any rendered page, and no HTML in stored values.
6. Submissions are personal data. Implement a configurable retention window, a
real delete-by-submission and delete-by-email path, and state the window in
the README.
7. Images are processed at publish: resized to the breakpoints actually used,
converted to a modern format, given explicit dimensions, and never served
at original size.
8. Every page renders with a title, meta description, canonical URL and OG
tags. Refuse to publish a page still titled Untitled.
9. Build exactly three blocks well — hero, text-and-image, footer — and prove
each at 320, 768 and 1440 before adding a fourth. Do not generate twenty
half-working blocks.
10. Out of scope, and say so rather than stubbing it: multi-user editing,
e-commerce, a CRM, and hosting sites for anyone other than me. If I ask
for client sites, tell me I am becoming a hosting provider.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
The moment there is a second editor, or a form that matters. Fifteen dollars a month buys the block library you cannot realistically reproduce, plus image processing, CDN, certificates and a form receiver that has already met the spam internet. If exporting the source code is part of your plan, note it is a Business-plan feature at twenty-five a month — still cheaper than the fortnight you would spend on breakpoints.
$15/mo is cheaper than your weekend.
The whole plan is the static export, which is why it belongs in the first sprint rather than the last. A folder of HTML, CSS and images serves from any bucket, survives your builder being abandoned, and is also what you would hand to Tilda, Webflow or a developer on the way out. What does not export is the form submission history, so keep that in a plain table you can dump to CSV.
Open-source visual website builder designed around web standards rather than a proprietary block format.
The web builder framework to embed if you want the canvas without writing the drag-and-drop engine yourself.
Questions
Why is a block library so hard to reproduce? It is just CSS.
It is CSS the way a font is vectors. Every block has to hold up with one word or twelve in the heading, with a portrait image where a landscape was intended, at three breakpoints, in Safari, with the site's own type scale applied. That is a design problem solved one block at a time by people looking at real output. An agent will generate you twenty blocks in an hour and you will find out which ones are broken from a screenshot somebody sends you.
Is Carrd not the same argument, and that one is SHIP IT?
Carrd is one page. That constraint removes navigation, URL structure, redirects, per-page metadata and most of the schema-migration problem in a single stroke. Tilda is a multi-page site builder with forms and a CRM attached, and the difference between one page and a site is exactly where the maintenance lives.
Where does the personal-data risk come from? It is a landing page.
From the form block, which is the reason most landing pages exist. A contact form is an endpoint strangers write to, and whatever they type is stored somewhere with their email attached. That is a retention policy, a deletion path and a spam problem, none of which are visible while you are building the drag-and-drop canvas.
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-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice