Should I vibe code
Build and manage one client-ready responsive site from reusable sections
The builder is a weekend. The hosting company you accidentally founded is not.
?
Their verdict, the Basic 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
Duda is not really a website builder, it is a hosting company with an editor bolted to the front — every site made on it is served by them, and that is the line item you would be replacing. The drag-and-drop demo lands in a weekend and looks great. What lands forever is certificate renewal on domains you do not own, a CDN bill that grows with someone else’s traffic, and a client whose contact form quietly stopped emailing three weeks ago. You did not build a builder. You founded a hosting provider with no status page and no second person.
What actually breaks
not "if". the specific failures.
- TLS renewal across twenty custom domains you do not control, where the failure mode is a full-page browser warning on a client’s homepage
- The contact form, silently — SPF and DKIM on a domain that is not yours, so the leads stop arriving and the first symptom is a client asking why business went quiet
- Responsive output, which is where visual builders actually die: the section that is perfect at 1440px and stacks wrong on the phone that most of the traffic is using
- The editor, the moment a client can paste raw HTML into a text block on a renderer that serves every other client from the same origin
- A client leaving, which in your version means exporting a site that only your renderer knows how to render
- Your weekends, because a website nobody can reach is an emergency to its owner regardless of what your contract says
A client rings on a Saturday because their site is showing a red interstitial and their busiest weekend of the year started an hour ago. The certificate for their apex domain expired at 04:00 UTC. Your renewal job runs weekly and has been failing since a DNS provider changed its API six weeks back — quietly, with the error going to a cron log that nothing reads. In that moment you are not their web developer. You are their hosting provider: no status page, no runbook, no on-call rotation, and nobody else on earth who knows how the renewal works.
Is that you?
the verdict is a default, not a law
- The only sites on it are your own
- It generates static files you hand to Netlify, Cloudflare Pages or S3, and you never serve a request yourself
- Nobody is paying you a monthly fee whose implied promise is that the site is up
- You are billing clients monthly for hosting, because that word is a promise with a number attached to it
- Client sites collect contact-form submissions that land anywhere other than a provider’s inbox
- You have signed anything containing the word “uptime”
- There is no way to wake you when a site is down, and no second person who understands any of it
If you build it anyway
the checklist, then the prompt that enforces it
- Generate static output and host it on somebody else’s platform. The editor is the fun part and the only part you should own.
- Automate certificate renewal, then monitor the renewal itself and alert on expiry at 30, 14 and 3 days. The job silently failing is the failure, not the certificate.
- Never render client-authored content as raw HTML on a shared origin. One stored XSS on a multi-tenant renderer is every client at once.
- Point contact forms at a form provider or a transactional email API on a domain you control. Do not send mail as your client’s domain.
- Build export before you build the editor: a client must be able to walk away with a folder of HTML that works without you.
- Put uptime monitoring on every client domain from the first launch, with alerts that reach a human. If you will not do this, you are not offering hosting, you are offering hope.
I am building a website builder that will serve sites for other people’s businesses. Apply these and argue with me when I try to skip one. 1. Before any code: tell me plainly that hosting other companies’ websites means their downtime becomes my emergency, and ask whether I would rather generate static output and let Netlify, Cloudflare Pages or S3 serve it. Default to that architecture unless I insist otherwise. 2. Build export first. A client must be able to download a folder of plain HTML, CSS and images that renders correctly with my system switched off. Write that before the editor, and write the test that proves it. 3. Certificates next. Automated issuance and renewal, plus an independent check that alerts a human at 30, 14 and 3 days before expiry. The silent failure of the renewal job is the actual incident — monitor the job, not just the certificate. 4. Uptime monitoring on every client domain before the first client goes live, with alerts that reach a phone. If I say I will add it later, refuse. 5. Never render client-authored content as raw HTML on a shared origin. Sanitise, or serve each site from its own origin. Explain the stored-XSS blast radius on a multi-tenant renderer before I ask for a custom code block. 6. Contact forms go to a form provider or a transactional email API on a domain I control. Do not configure sending as a client’s domain, and add a delivery check that alerts when submissions stop arriving — silent form failure is the bug clients notice last and forgive least. 7. Mobile layout is not a later pass. Build the responsive model into the section primitives from the first component, and show me every section at 375px in the preview by default. 8. Deliberately out of scope until I say otherwise: ecommerce, client logins, analytics, a plugin system, anything that stores a visitor’s personal data. 9. Write a README section titled “What I have promised these clients” and make me fill it in — uptime, backup frequency, restore time, who to call. 10. Then tell me what Duda charges to be that company instead of me.
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 anyone is paying you for a website to be up, buy it. Twenty-five dollars a month buys a company with a CDN, a status page, an on-call rota and a certificate pipeline that has already broken and been fixed a thousand times on somebody else’s Saturday. Build the design system, sell the design work, rent the servers.
Static export, tested, from day one — a client site has to be a folder of HTML that renders with your system off. That single constraint turns shutting down from a migration project into an email with a zip file attached, and it is the only thing that makes handing clients back to a real platform survivable. Keep DNS in each client’s own registrar account, never yours, or the exit involves domains you legally cannot transfer.
Open-source visual website builder designed around web standards.
Questions
What if I only use it for my own sites?
Then most of this entry evaporates and it is a decent weekend project — the risk here is almost entirely about serving other businesses. Generate static output, host it somewhere managed, and enjoy it. The moment a client is paying you monthly, re-read the guardrails: the code did not change, but who pays when it breaks did.
Why is the responsive layout listed as a thing that breaks rather than a thing that is hard?
Because it does not break for you. It breaks on a visitor’s phone, on a page you have only ever opened on a laptop, and nobody tells you — they just leave. Visual builders make this failure invisible by design, which is precisely why the commercial ones spend so much of their engineering budget on the breakpoint model rather than on the drag-and-drop.
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.
A text-first site builder is a static site generator with a nicer front door. You already own three of those.
A public form is a database strangers can write to. Yours also emails you the contents and has no backup.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice