Should I vibe code
Build a small responsive site with pages, collections, and simple forms
Building the site is the good weekend. Building the editor your client logs into on Tuesday is the bad decade.
?
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
Two products share this page and only one of them is a weekend. The site Dorik outputs — a small marketing site with a blog, a collection or two and a contact form — is among the best things you can point an agent at: static files, a CDN, better Lighthouse numbers than any template, done Saturday and genuinely nicer than what you were replacing. The thing Dorik actually sells is the editor: a visual builder with collections, a white-label dashboard and a client who logs in on Tuesday to change the opening hours without phoning you. That second product is a CMS, an auth system, an image pipeline, a preview environment and a support rota, and none of it is the fun part. The moment there is a client, all the boring infrastructure becomes a promise to somebody else's business — their domain, their certificate renewal, their form submissions accumulating in your database under their privacy policy. Build the site by hand. Rent the builder, or hand the client something that already has an editor in it.
What actually breaks
not "if". the specific failures.
- Certificate renewal on a client's domain, on a Sunday, presenting to every visitor as a full-page browser warning rather than a quiet 500
- The contact form, about three days after launch, once bots find an unauthenticated POST with no rate limit, no honeypot and a mail relay behind it
- Form submissions piling up as names, emails and messages in a database with no retention rule, no deletion path and no named owner
- The CMS you added so the client could edit copy, which is an authentication system you now maintain for someone who reuses passwords
- Images, the first time somebody uploads a 12MB photo straight from a phone and the homepage starts shipping it at full resolution
- The gap between editing and publishing, because you never built a draft state and the client is now editing production
- Every copy change becoming a pull request only you can merge, including the fortnight you are away
- The DNS record, moved by someone at the registrar to fix an email problem, taking the site with it
Is that you?
the verdict is a default, not a law
- The site is yours, static, and you are the only person who will ever edit it
- The contact form posts to an established form service rather than to code you wrote
- The build outputs files to a managed host, so a broken deploy still leaves yesterday's site being served
- Nothing on the site is the difference between a business trading and not trading
- A non-technical owner needs to change prices, copy or opening hours without you
- You are building it for a client and there is no second person who understands the deploy
- It takes payments or bookings, which is a different and considerably worse entry
- You were planning to build the visual editor itself, because that is a product, not a project
If you build it anyway
the checklist, then the prompt that enforces it
- Static output on managed hosting. A failed build should leave yesterday's site up — that single property removes most of the risk in this category.
- Send form submissions to an established form provider, or at minimum put a rate limit, a honeypot and a captcha in front of your endpoint before launch, not after the first spam wave.
- Write the retention rule and the deletion job in the same commit as the submissions table. Names and messages have a lifetime, and someone will eventually ask you to delete theirs.
- Automate certificate issuance and renewal, then monitor the renewal job rather than the certificate, and alert at 30, 14 and 3 days.
- Decide who edits the copy before you start. If the answer is not you, that is a CMS with logins and it is a separate project with a separate budget.
- Resize and re-encode every uploaded image at build time with a hard ceiling on dimensions, so a phone photo cannot become the homepage's performance budget.
- Keep the domain in the owner's registrar account, never yours. It is the difference between handing the site back and negotiating about it.
- Put uptime monitoring on the domain before launch, alerting somewhere that reaches a human at the weekend.
I am replacing a small Dorik site with something I build. Keep the scope
honest and push back — most of the cost here is in the parts that are not the
website.
1. First question, before any code: who edits this after launch? If the answer
is anyone other than me, say plainly that we are discussing a CMS with
logins, and scope that separately instead of bolting an admin panel on.
2. Static output on managed hosting — Cloudflare Pages, Netlify, S3. A failed
build must leave the previous site serving. No origin server unless I can
name the feature that requires one.
3. The contact form goes to an established form provider. If I insist on my own
endpoint, build the abuse controls first: per-IP rate limit, honeypot,
captcha, size cap, and no user input in an outbound email header. An open
form with a mail relay behind it becomes a spam cannon within days.
4. Write the retention rule and the deletion job in the same commit as the
submissions table. Tell me the default window you chose and why.
5. Certificates issued and renewed automatically, with monitoring on the
renewal job — not on the certificate — alerting at 30, 14 and 3 days.
6. Every image is resized and re-encoded at build time with a hard maximum
dimension, and the build fails if an unoptimised original ships.
7. Uptime monitoring on the domain before launch, alerting to a phone. If this
site is for someone else's business, its downtime is their revenue.
8. Accessibility is not optional polish: real heading order, alt text enforced
at build time, visible focus states, contrast checked in CI.
9. Keep the domain in the owner's registrar account and document the handover
in the README: DNS, host, repo, form provider, monitoring.
10. Out of scope: payments, bookings, customer accounts, comments and anything
that emails a list. Each is its own project and its own risk.
11. Finish by telling me what Dorik Personal costs month-to-month and what its
lifetime licence costs, then ask whether I want to own an editor.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
Somebody who is not you needs to edit the site. Twenty-nine dollars a month — or a one-off lifetime licence, which is less than a day of your time — buys an editor a non-technical owner can use, hosting with a status page, certificates that renew without you, and a support address that is not your phone. Build the marketing site by hand if you want; it will be faster and better looking. Just do not become the CMS.
$29/mo is cheaper than your weekend.
Keep the site as a folder of static files generated from content you own — markdown, JSON, whatever — with the domain in the owner's registrar account rather than yours. Then handing it over is an email, and moving to a hosted builder is re-theming rather than rescuing. The thing that traps people is the CMS: once copy lives in a database only your admin panel can write to, migrating means somebody retyping the site. Export the content to flat files on a schedule and the exit stays cheap.
Open-source visual website builder designed around web standards rather than a proprietary page format.
Long-running open-source web builder framework, and the honest measure of how much work a visual editor really is.
Questions
If it is just my own portfolio, is this still demo-only?
No, and that is worth saying clearly: for a site only you edit, with no form or with a hosted form, the answer is build it. A static generator plus an agent that knows CSS will beat any template on speed, accessibility and how it looks on a phone. The verdict is aimed at what Dorik actually sells, which is a builder other people use, on domains other people care about.
What is the most underestimated part?
The contact form. It looks like ten lines and it is the only unauthenticated write endpoint on an otherwise static site, which makes it the whole attack surface. Without a rate limit it becomes a spam relay; without a retention rule it becomes a compliance question; and if user input reaches an email header, it becomes an injection vector. Use a form provider unless you have a reason not to.
Dorik has a lifetime licence. Does that change the maths?
Considerably. A one-time payment for a single site, against a project you will be maintaining for as long as the site exists, is not a close comparison for client work. Subscriptions are what make self-hosting attractive; a lifetime licence removes most of that argument and leaves you buying an editor, a host and someone else's on-call rota for less than a day's rate.
- GDPR Art. 5 — principles relating to processing of personal data
- GDPR Art. 32 — security of processing
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.
The builder is a weekend. The hosting company you accidentally founded is not.
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.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice