Should I vibe code
Managed Ghost hosting for blogs, newsletters, and paid memberships
Paid memberships mean people are owed access. Access has to survive your enthusiasm.
?
Their verdict, the Publisher price and the build-time estimate come from their entry, MIT-licensed. Checked 2026-08-03.
?
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
A blog you should absolutely self-host. Once money and gated content enter, you have subscribers with a contractual expectation, and churn-by-outage is a refund conversation.
What actually breaks
not "if". the specific failures.
- Saved payment methods, which cannot be exported — moving membership systems means every member re-enters a card, and most never do
- Tier gating that fails open on an error, publishing the paid archive to everyone
- Member email, which is both the newsletter and the receipt channel, inheriting every deliverability problem at once
- An outage during a billing cycle, so people are charged for a week they could not read anything
- Your own enthusiasm, against subscribers who have paid twelve months forward
Two years in you want to move off your homemade membership layer onto something maintained. You export the members table — names, emails, tiers, renewal dates, all of it clean. Then you discover the part that does not come with you: the cards. Payment methods live with the processor under the integration you set up, and the new system cannot inherit them. Migrating means asking 900 paying members to re-enter their card. You will not get 900 back. You will get about half, and the half you lose were the ones who forgot, not the ones who left.
Is that you?
the verdict is a default, not a law
- The blog is free and there is no membership tier to enforce
- You self-host Ghost itself rather than writing a publishing platform
- Payment is a one-off tip jar, not a recurring entitlement
- People pay monthly for access to gated content
- Tier checks are not proven to fail closed
- You have not tested what a migration to another platform would cost you in members
- You are writing your own CMS when Ghost is open source
If you build it anyway
the checklist, then the prompt that enforces it
- Self-host Ghost rather than rebuilding it. The publishing engine is not where the risk is, and this removes most of this entry.
- Keep subscriptions in the payment processor, not modelled in your database, so the billing relationship can outlive your app.
- Tier checks fail closed. An error, a timeout, or an unknown state denies access — never grants it.
- Separate transactional member email from the newsletter send, so a campaign problem cannot stop a receipt or a password reset.
- Write the shutdown plan before launch: how members get refunded, and how much notice they get. Publish it.
- Before building, do the arithmetic on card migration. If you cannot move saved payment methods, you are choosing a platform for the life of the membership.
Before you build a publishing platform with paid memberships, apply these and push back if I ask you to break them.
1. Ask me why I am not self-hosting Ghost, which is open source. If I have no
specific answer, tell me to do that — the publishing side is solved and the
membership side is where the consequences are.
2. Before writing billing code, tell me that saved payment methods generally
cannot be moved between platforms, and that this makes my choice of billing
integration effectively permanent for existing members. Make me acknowledge
that in writing.
3. Keep subscription state in the payment processor and treat my database as a
cache of it. Add a scheduled reconciliation that reports drift.
4. Every access check for gated content fails closed. Show me that no exception
path, timeout, or unknown subscription status results in access being
granted.
5. Handle the full subscription lifecycle before launch: created, updated,
cancelled, payment failed, payment recovered. Refuse to ship with only the
grant path.
6. Separate member transactional email — receipts, resets, access links — from
newsletter sending, with different identities, so a campaign problem cannot
break a receipt.
7. Build self-service cancellation and refund in the first release.
8. Write a 'what happens if this shuts down' section in the README covering
refunds and notice period, and publish it where members can read it before
they pay.
9. Out of scope unless I ask: multi-author workflows, comments, recommendations.
10. Tell me that $35 a month is roughly one member's annual subscription, and
that losing half my members to a forced card migration costs far more.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
If money is involved, yes. Ghost Pro at $35 a month is the same open-source software with someone else owning uptime, billing edge cases and the migration path. Self-hosting the free version is also a good answer; writing your own membership billing is the one that traps you.
$35/mo is cheaper than your weekend.
There mostly is not one for the payment methods, which is why this decision is heavier than it looks — so choose the billing integration as if it were permanent. Keep content in Markdown files and members exportable with tiers and renewal dates, so at least the content and the relationships move even when the cards do not.
The product's own open-source publishing platform.
Questions
Why can't saved cards be migrated?
Card details are held by the processor under the account and integration that collected them, and moving them to a different platform's account is restricted — sometimes possible via a formal processor-assisted migration, often not, and never as a simple export. Plan as though it is impossible, because for most small publishers it effectively is.
Self-hosting Ghost is fine but building my own isn't. What's the difference?
Self-hosting gives you the same membership, billing and gating code that thousands of paid publications rely on, with someone else fixing it. Building your own means you own the tier checks, the webhook handling and the reconciliation — and every one of those failing wrong means either giving away paid content or charging people for content they cannot read.
- PCI DSS — official standards library
- Stripe — how Checkout reduces your PCI 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.
last reviewed 2026-08-03 · verdict is editorial and unsponsored · shared entry data from canivibecodeit under MIT · not legal advice