Should I vibe code
Websites, funnels, ecommerce, memberships, and CRM in one platform
The page builder is the demo. The one-click upsell is a second charge on a card the buyer already put away.
?
Their verdict, the Starter 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 category says website builder and the feature list says something else entirely: funnels with one-click upsells and downsells, a store with variants and discount codes, memberships with recurring payments, a CRM, and a broadcast engine that also sends SMS and WhatsApp. The builder is the demo — GrapesJS gives you a drag-and-drop canvas in an afternoon and it looks exactly like the product. What sits underneath is not a website. A one-click upsell is a second charge against a card the buyer has already put away. A membership is a subscription biller, which means dunning, proration, failed cards and a cancellation flow people will find. A broadcast tool is your domain's sending reputation pointed at a list somebody pasted in. Each of those is its own build with its own entry on this site, and the reason this lands in the your funeral band rather than the demo one is that nobody builds them one at a time — they land together, on a schema designed on Saturday, taking money from strangers by Monday.
What actually breaks
not "if". the specific failures.
- The order bump and the one-click upsell, which are both "charge that card again, after they thought they had finished" — the single most refund-generating pattern in online commerce
- Subscriptions, because recurring billing is dunning, proration, card expiry, involuntary churn and a self-serve cancellation, not a nightly job that calls charge()
- The fulfilment webhook, which is the thin thread between a successful payment and the customer getting anything at all, and which fails silently during your deploy
- Sending reputation, on the first broadcast to a list of five thousand addresses of unknown provenance, from a domain you also use for invoices
- Tax, quietly and expensively: a digital product sold to a buyer in the EU has a VAT question your code answers by never asking it
- Split tests in the funnel, which are a statistics problem your build will implement as "whichever variant sold more today"
- The membership area, which is your own authentication guarding paid content — exactly the auth this site keeps telling you not to write
- Publishing, if the live site renders from the same database as the editor, because then a bad save takes the customer's shop down rather than their draft
- Coupons, which get shared, and inventory, which oversells, both for the same reason: the check and the decrement are two statements instead of one
The launch goes better than expected, which is the problem. Checkout is hosted and behaves perfectly, the money is visibly landing in the processor's dashboard, and the thing that actually grants the download is a webhook handler you wrote in twenty minutes because it was the last piece. At 01:40 you push a copy fix to the sales page. The container restarts, the handler returns 502 for about ninety seconds, and the processor does exactly what it documents: retry with backoff, then keep retrying, then eventually stop. Forty-three people have paid and have nothing. Nine of them email, which is the good outcome. Two of them do the thing that costs most and open a dispute with their bank, because a card charge with no product looks like fraud from the outside, and disputes are the number the processor watches rather than the refunds. A new merchant account crossing the dispute threshold in its first week is an account under review, and payouts get held for thirty days — which is the money your customer was counting on to pay for the ads that caused the launch.
Is that you?
the verdict is a default, not a law
- It is a marketing site, and the checkout is a hosted payment link that lives entirely on the processor's domain
- Nothing recurs. One-off payments only, no memberships, no subscriptions, no saved cards you charge again later
- Email goes out through a real sending provider with double opt-in, on a subdomain you are willing to burn
- You build the pages with GrapesJS or Webstudio and the store with Medusa, rather than writing either
- You are charging a card a second time after checkout — upsells, bumps, downsells, anything one-click
- You are running subscriptions, because billing is a product and dunning is where it lives
- You are hosting other people's shops, at which point their buyers' orders and refunds are your 3am
- The sender is yours, the list is theirs, and nobody can show where the addresses came from
If you build it anyway
the checklist, then the prompt that enforces it
- Take money only through hosted checkout, and treat your own database as a cache of what the processor already knows. No card fields, ever.
- Make the webhook handler the most defensive code in the project: signature-verified, idempotent on event id, persisted before it does anything, replayable by hand, and alarmed when it fails twice.
- Grant entitlement in one function called from exactly one place, so "they paid and got nothing" has a single line to inspect and a single line to fix.
- If you must have upsells, require a fresh confirmation with the amount displayed, and make the charge idempotent on a key derived from the order rather than the click.
- Do not write subscription billing. Use the processor's billing product, including its dunning emails and its customer portal for cancellations.
- Separate publishing from editing: the live site is a built artefact swapped in atomically, so a broken save never takes down the shop.
- Send through an established provider on a dedicated subdomain, with double opt-in, a working unsubscribe in every message, and a hard cap on the first few broadcasts while the domain warms.
- Answer the tax question before the first sale, in writing, per jurisdiction you are willing to sell into — or restrict sales to the ones you have answered.
I am building a website-plus-funnel platform: pages, a checkout, upsells, memberships and an
email broadcast tool. The page builder is the least dangerous part. Build in this order and
argue with me when I want to move faster.
1. Start with the money path, not the canvas. Hosted checkout only; my server never sees a card
field. If I ask for an embedded card form, refuse and explain the PCI scope I would take on.
2. Write the webhook handler before the success page: signature verification, idempotency on
event id, persist the event before acting, a replay command, and an alert when delivery
fails twice in a row.
3. Entitlement — what the buyer actually gets — is granted by one function called from one
place, and it is safe to call twice. Test the same event arriving three times.
4. Build the "paid but got nothing" reconciliation job early: list processor charges with no
fulfilment record, runnable on demand.
5. If I ask for one-click upsells, require a confirmation showing the amount, key the charge
idempotently off the order rather than the click, and tell me plainly that this is the
pattern that generates disputes.
6. Do not implement recurring billing. Use the processor's subscriptions, dunning and hosted
customer portal for cancellation. If I insist, refuse and explain proration.
7. Memberships gate content server-side on every request. No client-side checks and no
unguessable URLs standing in for authentication.
8. Keep publishing separate from editing: build to a static artefact and swap it atomically, so
an editor save can never take a live shop down.
9. For email, use an established sending provider on a dedicated subdomain. Require double
opt-in, put a working unsubscribe in every message, cap the first broadcasts while the
domain warms, and refuse to send to an imported list with no consent record.
10. Ask which countries I sell to and what the tax treatment is before the first sale. With no
answer, restrict the checkout to where I have one.
11. Use GrapesJS or Webstudio for the canvas and an existing commerce engine for the store.
Hand-roll neither.
12. Out of scope unless I ask again: CRM, SMS, WhatsApp, affiliates and white-labelled
sub-accounts. Each is another product with another failure mode.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 are selling anything to anybody. $18 a month gets you the site, $36 adds funnels and $49 adds the store — all of which is less than one disputed transaction and considerably less than a fortnight of your evenings spent on dunning logic. The honest split is that a marketing site is a perfectly good thing to build yourself, and everything downstream of the buy button is not: buy the checkout, buy the billing, buy the sender, and spend your weekend on the part that is actually yours.
$18/mo is cheaper than your weekend.
Two things have to survive and neither is the builder. The first is the money: keep the processor as the system of record, with your order id in every charge's metadata, so the ledger exists even if your app does not. The second is the list and the orders — export contacts, consent state and order history to CSV on a schedule, because that is the asset and it is the only thing a migration to a real platform actually needs. The pages themselves should be exportable as static HTML with assets, which also means an outage never has to be an emergency; you can publish the last export while you fix things. Subscriptions are the piece with no clean exit: if you built your own biller, migrating live subscribers to a real one means re-collecting payment details, so use the processor's from day one and the problem never exists.
Open-source web-builder framework that gives you the drag-and-drop canvas, which is the half of this you should never write yourself.
Open-source visual website builder with a modern responsive model and its own publishing pipeline.
Open-source commerce engine covering carts, orders, discounts and fulfilment — the part of Simvoly that carries the risk on this page.
Questions
Dorik and Tilda are demo only. Why is this website builder in the your funeral band?
Because a website that takes money is not a website. Dorik's failure mode is that you get bored maintaining a CMS; the pages are yours, the visitors are readers, and the worst case is a stale site. Simvoly's product is a checkout, a subscription biller and a bulk sender wearing a page builder as a front end. The moment a stranger's card is charged by your code, or five thousand emails leave over your domain, the person who pays for the bug stops being you.
Can I not just bolt Stripe Checkout onto a static site and be done?
Yes, and that is the recommendation. Hosted checkout on a static marketing site is genuinely a good weekend and keeps you in the smallest possible scope. What this entry is about is everything after the payment succeeds: the webhook that grants access, the upsell that charges again, the renewal next month, the refund, and the customer who has paid and received nothing. That code is short, boring and where all the damage lives.
What specifically goes wrong with the email side?
Reputation, and it is not recoverable on your timescale. Deliverability is decided by receiving mail providers based on complaint rates, spam-trap hits and history, so one broadcast to a list of uncertain provenance can put your domain in the spam folder for months — including the invoices and password resets you send from the same domain. Use a real sending provider, a dedicated subdomain, double opt-in and a working unsubscribe, and never send to addresses you cannot show consent for.
- PCI DSS standards library
- Stripe — reducing your PCI scope
- CAN-SPAM Act compliance guide (FTC)
- EU VAT invoicing rules (European Commission)
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.
The builder is a weekend. The hosting company you accidentally founded is not.
Courses, community, email and payments. Pick one to vibe code. Not four with a checkout attached.
last reviewed 2026-08-05 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice