Should I vibe code
Authentication, gated content, subscriptions, and member data for websites
A paywall that JavaScript removes is a paywall that View Source removes.
?
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
Two of the three hardest things on this site, bolted together and sold for 29 dollars. Memberstack is authentication — signup, login, reset, sessions, social login, SSO — plus recurring billing, plus the entitlement check that decides whether a person sees the page. An agent will produce all three in an evening and every one of them will look correct. The one that gets you first is the gate: on a static or Webflow site, gating content means gating it in the browser, and a paywall implemented as a class that JavaScript removes is a paywall that View Source removes. The one that gets you longest is the billing, where a cancel that updates your database without calling Stripe keeps charging somebody who is certain they left, and you find out months later as a dispute rate. And your session token is sitting in localStorage on a page where a marketing colleague can paste a third-party script into an embed without asking anybody. This is the exact combination this site exists to warn about.
What actually breaks
not "if". the specific failures.
- The gate itself, because gating on a static site means the browser decides, and content that arrives in the page and is then hidden was never gated at all
- Session tokens in localStorage, on a site where anybody with CMS access can add a third-party script and read them
- Password reset, the most attacked flow in any application and the one an agent will implement with a guessable token, no expiry and no single-use check
- Cancellation that flips a column and never calls Stripe, so the card keeps being charged by somebody who has already stopped logging in
- Dunning: the card that expires in month nine, the retry schedule nobody wrote, and a paying member silently locked out because one renewal soft-declined
- Webhook handlers with no signature verification, which let anybody who learns your endpoint URL grant themselves a membership
- Webhook ordering and replay, since Stripe delivers at least once and out of order, and "subscription updated" arriving before "created" is normal rather than exceptional
- Proration on plan changes, which is arithmetic you will get generously wrong once and meanly wrong forever
- Email enumeration on login and reset, which turns your member list into something any script can test addresses against
It is not the authentication that surfaces first. The members' area was built the obvious way for a static site: the whole page ships to the browser, and a script strips the locked class once the membership check returns. Somebody posts the URL in a Discord with the words "just turn off JavaScript", and for a fortnight the paid course is simply the website. You learn about it from a member asking, politely, what exactly they are paying for. Fixing it means moving the content behind an authenticated fetch, which means the session token you kept in localStorage now has to be worth something — and that token was minted by your own code, never expires, cannot be revoked, and has been readable by every third-party script the marketing site has loaded since launch. Neither of these is a bug you patch on Thursday. They are the two decisions the whole thing was built on.
Is that you?
the verdict is a default, not a law
- Nothing is genuinely private — the members' area is a convenience, and everything inside it could be public tomorrow without consequence
- Authentication is delegated end to end to a provider that owns passwords, sessions and resets, and your code only verifies a signed token
- Billing is a Stripe Checkout link plus a Customer Portal link, with Stripe holding the whole subscription lifecycle and your app reading state rather than managing it
- There are ten members, they are all colleagues, and anything that goes wrong can be fixed by hand in an afternoon
- You are writing password hashing, session issuance or the reset flow yourself
- Content is gated by hiding it after the page has loaded
- Cancellation is anything other than a call to Stripe whose result you read back
- Webhook handlers do not verify signatures, or are not idempotent on the event id
- The site is one a non-engineer can paste scripts into
If you build it anyway
the checklist, then the prompt that enforces it
- Do not write authentication. Use a provider — Clerk, Auth0, Ory, Supabase Auth, WorkOS — and let your code do exactly one thing, which is verify a signed token. This is the single highest-leverage decision on the page and everything else is downstream of it.
- Gate on the server. Premium content is fetched with a verified token and never rendered into a page that is subsequently hidden. If the site platform cannot render server-side, put the content behind an authenticated API on a domain you control and fetch it in.
- Stripe is the source of truth for subscription state; your database caches it and never decides it. Cancel calls Stripe, and the row changes when the webhook says so rather than when the button was clicked.
- Verify webhook signatures, make every handler idempotent on the event id, and handle out-of-order delivery deliberately, because Stripe guarantees neither ordering nor exactly-once.
- Never keep a session token in localStorage on a site where somebody else can add a script tag. HttpOnly, Secure, SameSite cookies, short expiry, refresh on the server, and a revocation path that works.
- Build deletion and export before signup. You are holding personal data from day one, and the day a deletion request arrives is not the day to design for it.
- Rate-limit login, signup and reset, and return identical responses for known and unknown addresses so the form is not a membership oracle.
I am building memberships for a website: signup and login, gated content, and
recurring Stripe subscriptions. Treat this as auth plus other people's money.
Refuse the parts you should refuse and build the safety-critical order.
1. Before anything, tell me not to write authentication, and name the
alternatives: Clerk, Auth0, Ory, Supabase Auth, WorkOS. If I insist on my
own, say once, plainly, that generated auth code looks correct and is subtly
wrong, and that the reset flow is where it usually is.
2. Build the gate on the server first. Content behind a membership is fetched
with a verified token and never shipped to the browser and hidden. If I ask
for a class that JavaScript removes, refuse and explain View Source.
3. Sessions are HttpOnly, Secure, SameSite cookies with a short expiry and a
working revocation path. Never localStorage — assume somebody can paste a
script tag into this site's CMS, because on Webflow they can.
4. Stripe is the source of truth for subscription state. My database caches it.
Cancel calls Stripe and the local row changes only when the webhook says so.
5. Verify every webhook signature, make handlers idempotent on the event id,
and handle out-of-order and replayed events explicitly. Write that test.
6. Never let card details near my server. Stripe Checkout and the Customer
Portal, hosted by them, so my PCI scope stays SAQ A.
7. Then dunning: what happens on a soft decline, how many retries, what the
member sees, and when access actually ends. Write it down even if the answer
is that Stripe handles it, because silently locking out a paying member is
the failure I will hear about last.
8. Rate-limit login, signup and reset, and return identical responses for known
and unknown email addresses.
9. Build member export and hard deletion before signup exists.
10. Finish by listing what I have taken on — password storage, session
revocation, breach notification, cancellation, dunning, refunds — and then
tell me Memberstack is 29 USD a month and that buying it is the right call.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
Now, and the 29 dollars is not really the comparison. Basic also takes a 4% transaction fee on top of Stripe, which at any real volume is expensive — that is exactly what the 499 dollar tier exists to remove, and even then the arithmetic favours buying. What you are purchasing is somebody else's password store, session revocation, cancellation flow and dunning schedule: four things that fail quietly, months apart, and always after you have moved on. If you want to own one piece of it, own the entitlement check and let a provider own the identity.
$29/mo is cheaper than your weekend.
The exit is the member list plus the Stripe customer and subscription ids, and the second half is the half that matters — as long as the subscriptions live in your own Stripe account, you can move the front end without touching anybody's billing, which is the single most useful property of this architecture. Keep an export that pairs each member with their Stripe customer id, their current entitlement and the date it started. What does not export is a password store: if you rolled your own, every member has to reset on migration, and a forced password reset email to a thousand people is indistinguishable from a phishing campaign.
Open-source publishing platform with built-in memberships, gated content and Stripe subscriptions — the closest honest analogue you can self-host.
Headless open-source identity and authentication service, if the answer is to own the auth half properly rather than write it.
Questions
Isn't "don't roll your own auth" a cliché by now?
It is, and the reason it survived is that generated authentication code looks exactly like correct authentication code. The password hash will be right, because that part is well documented. What will be wrong is quieter: a reset token that is a UUID with no expiry, no single-use check and no invalidation of existing sessions; a login response that reveals whether an address is registered; a JWT with no revocation path, so logging out is a client-side gesture. None of those show up in testing. All of them show up in a disclosure email.
Everything goes through Stripe Checkout. Am I still exposed on the money side?
Your PCI scope is genuinely small, and that is the right architecture. What Checkout does not do is decide when somebody stops being a member. Cancellation, dunning, proration, refunds and the entitlement boundary all live in your code, and every one of them fails in the direction of continuing to charge a person who thinks they have left. That is not a PCI problem, it is a chargeback problem, and it arrives months after the bug.
What is the smallest version of this that is actually safe?
Identity from a provider, entitlement from Stripe, and one function of yours that reads a verified token, asks Stripe what that customer is entitled to, and serves or refuses the content from the server. That is a small amount of code you can read in one sitting, and it removes the password store, the session store and the subscription state machine in one move. Everything on this page that goes wrong lives in the three things you just deleted.
Why does gating on a static site keep being called out separately?
Because it is the one failure that has nothing to do with auth and everything to do with the platform. On a server-rendered site, refusing to render the content is the natural implementation. On Webflow or a static export, the natural implementation is to ship everything and hide some of it, and that is not access control — it is a suggestion. Anybody who opens developer tools, disables JavaScript or reads the page source has full access, and you cannot fix it without moving the content somewhere the browser cannot reach unauthenticated.
- GDPR Art. 32 — security of processing (EU)
- Stripe — reducing your PCI compliance scope
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.
Cancel has to actually stop the charge. A cancel button that only hides the row is a fraud claim with a UI.
Paid memberships mean people are owed access. Access has to survive your enthusiasm.
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