Should I vibe code
Community platform for memberships, courses, live events, and payments
A forum is a weekend. A paid community is a company that five hundred strangers have already given their card to.
?
Their verdict, the Professional/Pro 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
Posts, threads and replies are a well-understood schema and an agent will give you a convincing forum before dinner. That is not what Circle is. Circle is the place several hundred people who paid you keep their private messages, their course progress and their card on file, and every one of those words is load-bearing. Paid means recurring billing you have to keep in step with Stripe. Private means per-object authorisation on every read, which is exactly the check generated code puts in the UI instead of the API. Several hundred people means moderation, which is a job and not a feature. It will work, and it will keep working right up until a member sees a conversation that was not theirs.
What actually breaks
not "if". the specific failures.
- Direct messages, where a generated app takes a conversation id from the URL, loads it, and leaves the "are you in this conversation" check to the UI that only ever links to your own threads
- Subscription state drifting from Stripe — one missed webhook and a paying member is locked out, or a cancelled one never is, and you find out from whichever of them is angrier
- Moderation, which arrives the week you get your first troll and is a rota, not a feature, at whatever hour your community happens to be awake
- Notifications at community scale, where a busy thread turns into one email per reply per member and your domain gets a new reputation overnight
- Deletion requests, because "delete my account" has to reach posts, replies, DMs, uploads, email logs, the payment record and the search index
- The archive itself: years of member-written posts in a schema only your application understands, with no export anyone else can read
- Uploads, since a community with an open door and a file field is a free CDN for whatever strangers want to host on your domain
A member forwards you a screenshot of a private conversation that is not hers, with a note asking whether this is normal. The message endpoint takes a conversation id, loads it, and renders it; the check that the requester is a participant lives in the UI, which only ever links to threads you belong to. Someone changed a number in the address bar. You cannot say how long that has been possible, and you cannot say how many conversations were read, because you log request paths and not who was entitled to the response. The entire premise members paid for was that the space was private, and the only honest thing you can put in the announcement is that you do not know.
Is that you?
the verdict is a default, not a law
- It is free, small and social — no memberships, no payments, no promise of privacy you cannot personally verify
- The members are colleagues rather than strangers who paid to be there
- There are no direct messages at all, and everything posted is visible to everyone in the space
- Losing the whole thing tomorrow would be annoying rather than a refund conversation
- Anyone pays a recurring fee for access
- Members send each other private messages
- You could not complete a deletion request today, across every table and every bucket
- Losing the archive would destroy something people spent years writing
- You are the only person who can restart it, and you sometimes go on holiday
If you build it anyway
the checklist, then the prompt that enforces it
- Authorise on the server, per object, on every request. Every read of a post, a DM or an upload asks whether this requester belongs to that space — never rely on the UI only rendering links people are allowed to follow.
- Let Stripe own subscription state and reconcile against it on a schedule. Access derived from a local `is_paid` boolean will disagree with reality the first time a webhook is dropped.
- Build export before anything else: every post, message and upload, per member, as files. It is your migration path and your deletion audit in one artefact.
- Implement deletion as an explicit enumerated list of every place a member's data lands, kept in the code where it will actually be updated when you add a table.
- Rate-limit signups, invites, messages and uploads on day one. A community with an open door is a spam target inside a week, and your domain wears it.
- Do not build direct messages if you can avoid it. It is the highest-consequence feature in the product and the one members assume is more protected than it is.
- Publish, in writing, what you store and for how long, and who can see it. If you cannot write that page honestly, the system is not ready for members.
I am building a membership community — posts, spaces, direct
messages and paid access. Treat authorisation and money as the product and the
feed as decoration. Push back if I ask for them in the other order.
1. Define the authorisation model in one place before any feature: who may read,
write and delete each object type, and how space membership is determined.
Every API handler consults it, including admin routes.
2. Never authorise by what the UI links to. Every request loading an object by
id re-checks the requester against that object's space — DMs, uploads,
comments, search. Write the test that fetches another member's thread and
expects a 404.
3. Build export before import and before the feed: every post, message and
upload, per member, as files. Migration path and deletion audit in one.
4. Then deletion. Enumerate every place member data lands — tables, object
storage, email logs, search index, caches — as a list in code, updated in the
same commit as any new table.
5. Stripe is the source of truth for subscriptions. Reconcile on a schedule
rather than trusting webhook delivery, make handling idempotent, and tell me
what happens to access during a failed payment before you write it.
6. Never store card details. If any part of the design has a card number
reaching my server, stop and say so.
7. Rate-limit signup, invite, post, message and upload from the first commit,
and serve uploads from a domain that is not the app's, with type and size caps.
8. Notifications get a digest and a per-member cap before they get a template.
One email per reply per member is how a young community burns its domain.
9. Do not implement DMs unless I insist. If I insist, say once that it is the
highest-consequence feature here, and build the participant check first.
10. Assume the community outlives my interest: everything member-written must be
exportable by someone who is not me, without the app running.
11. In the README write "What members are trusting me with" and list it plainly.
Then tell me what Circle costs, and that the real comparison is who is awake
when login breaks on a Sunday.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
As soon as money or private messages are involved, which for Circle is immediately. $99/month across two hundred paying members is under fifty cents a head, and what it buys is not the forum — it is somebody else's on-call rotation, somebody else's authorisation tests, and a company that can answer a deletion request while you are asleep. If the community is free and public, self-host Discourse instead and skip both.
$99/mo is cheaper than your weekend.
Decide in week one that content is portable, because you cannot retrofit it. Posts and replies as markdown with stable ids and authors, uploads as files, members as a CSV, and a documented mapping — Discourse and every other platform will import something close to that shape. The part with no exit is the payment relationship: migrating a paid community means every member re-subscribing somewhere new, so run both in parallel and expect to lose the ones who never get round to it.
Mature open-source community/forum software suitable for many Circle-like communities.
Questions
canivibecodeit says KINDA. Why are you harsher?
Because they are answering whether an agent can produce a working community platform, and it can — the schema is well understood and the feed will look right on the first try. Our question starts after that. The failure here does not land on you deleting a repo; it lands on members who paid for a private space, and the specific bug that exposes them is the one generated code is most likely to contain.
What if I skip payments and just charge people offline?
That removes the entire money-movement half and is a genuinely different project — no billing reconciliation, no failed-payment access logic, no refunds. What remains is still other people's private conversations on your server, so authorisation and deletion are unchanged. It moves the entry down a band, not off the list.
Isn't Discourse just this, already built?
For a free public community, more or less, and self-hosting it is a much better use of a weekend than writing your own. It is a weaker fit where Circle earns its price — paid memberships, courses and events under one login — which is also precisely the part where building your own gets expensive.
- GDPR Art. 5 — principles relating to processing of personal data (EU)
- GDPR Art. 32 — security of processing (EU)
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.
A community isn't a feature you ship. It's a duty of care with a subscription attached and a report button.
The queue is a weekend. Posting to someone else’s account on their behalf is not.
Client social accounts are the one place where “it double-posted” is a phone call, not a ticket.
last reviewed 2026-08-04 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice