Should I vibe code
Visual website design and publishing with Figma import and collaboration
Figma is absolute positions at one width. The web reflows at all of them. An importer is a guess, not a conversion.
?
Their verdict, the Solo 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
Siter's promise is that the artboard is the website: lay it out the way you would in Figma, import the frames, publish to a custom domain. The reason that is a product rather than a script is that Figma describes absolute positions at one canvas width and the web describes text that reflows at all of them, and no importer converts the first into the second — it guesses, and then somebody fixes it by hand at four breakpoints. Rebuild it and you will have a canvas editor producing genuinely handsome desktop-only pages by Sunday night, followed by a month on the responsive model, which is the actual product. The half nobody scopes is that publishing means running a small hosting company: custom domains, a certificate that renews every ninety days or doesn't, an atomic swap so nobody catches a half-deployed site, and a contact form sitting unauthenticated on the open internet collecting the only personal data in the entire system. Nothing here lands on a stranger's money or health, which is why it stays in the demo band. It just never finishes.
What actually breaks
not "if". the specific failures.
- Responsiveness, which is the entire distance between a Figma frame and a web page, and the one thing an import cannot carry across
- Text metrics, because the same string is a different width in Figma and in Chrome — absolutely positioned text overlaps at exactly the viewport you did not test
- Fonts, which look right on your machine because they are installed on your machine
- The publish step, if it is not atomic, which is how a visitor gets a page whose stylesheet has not finished uploading
- TLS renewal for custom domains, which works beautifully for eighty-nine days and then does not, at a time nobody is watching
- The form endpoint, an unauthenticated POST on the public internet that spam bots will find within days of the site going live
- Where submissions go, which is the only place a site builder touches personal data and the place nobody designs — an inbox, a table, no retention, no export
- Undo and version history in the editor, which every user assumes exists and no canvas gets for free
- Everything that is not a page: a blog, redirects, a sitemap, a 404, and the CMS you swore this project would not need
Is that you?
the verdict is a default, not a law
- It builds your own sites, and "publish" means writing static files to a host somebody else operates
- You take the canvas from GrapesJS or Webstudio instead of writing an editor
- Forms post to an existing form service, or to an endpoint with a captcha, a rate limit and a fixed recipient
- Static export exists from the first week, so the output is HTML you own rather than rows in your database
- Clients' sites are published from it and you are the reason their certificate renews
- The form emails whatever address the page supplies, which makes your server a relay for whoever finds it
- There is no export, so the pages exist only inside a tool with one maintainer
- You are selling it, at which point somebody else's business hours depend on your deploy pipeline
If you build it anyway
the checklist, then the prompt that enforces it
- Write the static exporter in the first week, not the last. A builder whose output is HTML and assets on disk is an experiment; one whose output is rows in your database is a commitment.
- Decide the responsive model before the editor — a grid, flow with constraints, or explicit breakpoints — because retrofitting reflow onto absolute coordinates is a rewrite, not a feature.
- Publishing writes to a new directory and swaps a pointer atomically, with the previous build kept for instant rollback. Never edit the live tree in place.
- Automate certificate issuance and renewal, then monitor the expiry date independently of the thing that renews it. The failure mode is silence, not an error.
- Treat the form endpoint as hostile: a rate limit per IP and per form, a bot check, a fixed recipient list on the server, size limits and no HTML in the payload.
- Give form submissions an owner and a lifetime — where they are stored, who can read them, how they are exported, when they are deleted — before the first form ships.
- Version every page save. A visual editor without history is one misplaced drag away from an afternoon of work, and users will not have a backup because you are the backup.
I am building a visual website builder: a canvas editor, an import from design files, and
publishing to a custom domain. Build it in this order and push back where I am optimistic.
1. Before the editor, define the layout model and write it down: how a design at one width
becomes a page at every width. Grid, flow with constraints, or explicit breakpoints. If I
say "absolute positions, it looks fine on my screen", refuse and explain what happens on a
phone.
2. Build the static exporter second, before any polish. One command produces HTML, CSS,
images and fonts in a folder that opens with a double click. That is the test of whether
the project is reversible.
3. Use an existing canvas — GrapesJS or Webstudio — rather than writing selection handles,
snapping and z-order from scratch.
4. Version every save. Keep the last fifty page versions with a one-click restore before you
add a single styling feature.
5. Publishing writes to a new directory and swaps a symlink or pointer atomically, keeping the
previous build for rollback. Never write into the live tree.
6. Automate certificates, then monitor expiry with something that is not the renewal job.
Alert me at thirty days, not at expiry.
7. Treat the form endpoint as hostile from the first line: per-IP and per-form rate limits, a
bot check, a maximum payload size, and a recipient list fixed on the server. The page must
never be able to name the recipient.
8. Decide where submissions live, who reads them, how they are exported and when they are
deleted, before the first form goes on a live site.
9. Measure text with the fonts that will actually load, and self-host them. Do not lay out
against metrics from my machine.
10. Add a per-site 404, a sitemap and redirects early. They are trivial now and archaeological
later.
11. Out of scope unless I ask: a CMS, blogging, e-commerce, memberships and multi-tenant
hosting for other people's clients. That last one turns this into somebody else's uptime.
12. Finish by telling me what it would take to run this for a client for a year, including
certificate renewals and browser changes.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
You want to publish sites rather than build a tool that publishes sites. Solo is $7 a month and Pro is $24, which is less than the hours you will spend on certificate renewal alone, and what you are actually buying is the responsive engine and somebody else's on-call. Worth noting before you commit either way: on Siter, downloading your own HTML is a Pro-tier feature, so if you build your own the single best decision you can make is to give yourself that export for free, on day one.
$7/mo is cheaper than your weekend.
The static export is the exit plan, which is why it belongs in week one rather than in the backlog. HTML, CSS, images and self-hosted fonts in a folder will deploy to any host on any afternoon, and it means an outage in your builder is never an outage for the site. Keep DNS and the domain registration in the site owner's account rather than yours, so handing the whole thing over is a conversation rather than a migration. The two pieces that do not survive are the editable document — that is proprietary to whatever you built, so version it as JSON alongside the export — and the form submissions, which live nowhere else and should be emailed or exported continuously rather than pooled in a table only your app can read.
Open-source visual website builder with a real responsive model and a publishing pipeline — the closest working answer to the hard half.
Open-source web-builder framework you can embed, which removes the canvas work and leaves you the layout model.
Questions
How is this different from the Dorik or Readymag verdicts?
The import is the pitch. Dorik sells blocks and a CMS; Readymag sells art direction. Siter sells the idea that the design file becomes the site, and that specific promise is where the work hides — because the thing being imported is a fixed canvas and the thing being produced has to survive a 375-pixel phone. Everything else in this category is shared, but that translation is Siter's product and it is the part your clone will not have.
How hard is the hosting half, really?
The first version is easy and the tenth month is not. Static files behind a CDN with automated certificates is a genuinely good weekend. What follows is the maintenance: a renewal that fails silently on a Sunday, a customer pointing an apex record at a CNAME, a cache that will not invalidate, and a browser update that changes how one of your generated layouts renders. None of it is hard. All of it is yours, permanently, and it is why this sits in the demo band rather than higher up the shelf.
Where does the actual risk in a site builder live?
The contact form. Everything else in the system is public by design — pages, images, styles — so the only personal data in the entire product arrives through an unauthenticated POST that anyone can find and script. Rate limit it, fix the recipient on the server so it cannot be used as a relay, cap the payload, and decide where submissions live and when they get deleted. That is a two-hour job that removes the only genuinely sharp edge on the page.
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.
Freeform means every element is a coordinate. The font falls back once and the whole page moves.
Tilda ships 550 blocks that survive a 320-pixel phone. Your agent will build the editor and nine blocks.
Building the site is the good weekend. Building the editor your client logs into on Tuesday is the bad decade.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice