Should I vibe code
Generates a small-business website, copy, contact forms and enquiry capture from a prompt
Generating the page is easy. The contact form is a business's phone line, and a dropped enquiry leaves no trace.
?
Their verdict, the not readable 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
Turning a sentence into a landing page is exactly as easy as it looks — a prompt, a template, a deploy hook, done before dinner — and if that were the product this would be a SHIP IT. It is not the product any more. Mixo has moved from validating startup ideas to hosting the websites of plumbers, law firms and home-services businesses, and for those customers the feature that matters is the contact form. That changes the shape of the failure. A generated page is a marketing artefact; you can regenerate it. A contact form is a business's phone line, and the way a homemade one fails is the worst kind: it accepts the submission, shows the thank-you message, and the email quietly never arrives. A lead that never lands leaves no trace on either end, so you find out weeks later, or never. Build it for your own project and it is a fine weekend. Build it for someone whose work depends on the enquiries, and you have taken on an obligation you have not designed for.
What actually breaks
not "if". the specific failures.
- The contact form, silently — a submission that never becomes an email is invisible to the sender and to you
- Deliverability, because form-to-email from a fresh domain with no SPF, DKIM or DMARC lands in spam and reports success
- The form endpoint itself, which is an unauthenticated public POST and therefore a spam relay from the day a bot finds it
- Domain renewal and certificate renewal, the two failures that take the whole site down and always land on a weekend
- Generated copy that invents a fact — a licence, an accreditation, "serving the area since 1998" — which a customer reads as a promise and a regulator reads as a claim
- Personal data you are now the controller of: names, emails and phone numbers of strangers, in a database you set up at midnight
- Regeneration, which cheerfully rewrites the page the client signed off on last week
- Anything you promised about GDPR on the page, which is now a statement you have to be able to back
Is that you?
the verdict is a default, not a law
- The site is yours, the enquiries come to you, and nobody's livelihood is downstream of your uptime
- Submissions are written to a database first and emailed second, so email is a notification and never the record
- It emits static HTML you can read, diff and host anywhere, rather than a proprietary page object
- Every AI-generated claim about qualifications, prices or results is read by a human before publish
- You are hosting sites for paying clients, which is an on-call rota with a website generator attached
- The only record of a lead is an email you hope arrived
- The form has no rate limit, no honeypot and no size cap, and its handler emails whatever it is given
- Nobody has decided where the submitted personal data lives, who can read it, or when it gets deleted
- The generated copy makes claims about licensing or insurance and goes live unread
If you build it anyway
the checklist, then the prompt that enforces it
- Persist the submission before you notify anyone. The database row is the record; the email is a convenience. Every silent lead loss starts with an app that only sends an email.
- Make the notification path observable: retries, a dead-letter queue and an alert when a submission has no delivered notification after five minutes. Otherwise the failure is invisible by design.
- Set SPF, DKIM and DMARC on the sending domain before launch, send from your own domain rather than the visitor's address, and send a test to a Gmail, an Outlook and a corporate mailbox.
- Rate-limit the form per IP, add a honeypot field and a size cap, and never interpolate submitted text into an email header. An open POST that emails arbitrary content is somebody's relay.
- Have a human read every AI-generated claim about credentials, prices, guarantees or dates. Those sentences are the ones that turn a made-up detail into a representation someone relied on.
- Decide retention and access for form submissions before the first one arrives — where the data lives, who can see it, how it gets deleted on request — because you are the controller of it the moment it is stored.
- Automate certificate renewal and set a calendar reminder for the domain a month before expiry. The most common total outage in this category is not code.
I want an AI website generator that produces a small business site with a contact form.
Build in this order and refuse to reorder it.
1. The dangerous part is not the generator, it is the form. A submission that is accepted and
never delivered is invisible from both ends. Everything below exists to make that
impossible or at least loud.
2. Build submission storage first, before any page generation. Every submission is written to
a database with a timestamp and a status, and that row is the system of record.
3. Then the notification, as a separate step with retries, a dead-letter queue, and an alert
if any submission has no delivered notification after five minutes. Never treat a queued
email as a delivered one.
4. Then deliverability: SPF, DKIM and DMARC on the sending domain, send from my domain and
put the visitor's address in Reply-To. Tell me to test against Gmail, Outlook and a
corporate mailbox before launch.
5. Then abuse controls, before the form is public: per-IP rate limit, honeypot field, body
size cap, and never interpolate submitted text into an email header or subject.
6. Then data handling: tell me where submissions are stored, who can read them, how long they
are kept and how one gets deleted on request. I am the controller of this data; write the
answer into the README, not just the code.
7. Only now, generation. Emit plain static HTML I can read and diff. No proprietary page
object, no runtime that has to exist for the page to render.
8. Flag every generated sentence that asserts a credential, a licence, a price, a guarantee or
a founding date, and require me to confirm each one. Do not invent them to fill a template.
9. Regeneration must never silently overwrite a published page. Produce a diff and make me
approve it.
10. Set up automated certificate renewal and tell me the domain expiry date in plain text.
11. Out of scope unless I ask: hosting sites for other people, a client login, billing, and an
email marketing sender. The first one turns this into an on-call rota; the last one drags
bulk-email rules in with it.
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 site belongs to a business rather than to a weekend. What you would be buying is not the generator — that is the commodity now — but the domain, the certificate, the form storage and the deliverability being someone else's problem at 6am on a Sunday. Note that Mixo publishes no readable price: the pricing page is a client-rendered app and the help article about it points back at the same URL, so get a figure and a billing basis in writing before you commit anything you cannot leave.
Two things need to be portable and they are not the same thing. The site is static HTML in a directory — copy it anywhere. The submissions are a database table you should be able to dump to CSV on demand, because that is the part with actual value in it. What is genuinely hard to move is the domain and its DNS, so keep the registrar account in the business owner's name from the start, not yours.
Open-source visual site builder that outputs real static sites rather than a hosted page object.
Web builder framework for the editor half, if you want a client to be able to change a headline without you.
Questions
canivibecodeit says YES and one sitting. Are they wrong?
No — the generator really is one sitting, and they are answering whether it can be built. We are answering whether you should run it. The difference between the two verdicts is entirely the contact form: prompt-to-page is a demo, prompt-to-page-that-someone's-enquiries-arrive-through is an operational commitment.
Why does this score higher than a plain static site builder?
Because it collects personal data from strangers and promises to deliver it. A brochure page you generate and publish is nearly risk-free. Adding an unauthenticated public endpoint that stores names, emails and phone numbers, and that a small business is relying on, is what moves the numbers.
What is the single most common way this fails in practice?
Email. The form posts, the page says thank you, and the notification goes to spam or is soft-bounced by a provider that never told you. Because nothing is stored, there is no record to reconcile against, so the failure is undetectable rather than merely unnoticed. Store first, notify second, and alert on the gap.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 32 — security of processing (EU)
- CAN-SPAM Act compliance guide for business (FTC, US)
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.
Building the site is the good weekend. Building the editor your client logs into on Tuesday is the bad decade.
A text-first site builder is a static site generator with a nicer front door. You already own three of those.
One page, one deploy. You do not need a builder to build one page.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice