Whop

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me a storefront that replaces Whop — and read the first paragraph, because the verdict turns on something you cannot build.

**The marketplace sends you buyers.** Whop is a payment layer and a discovery channel, and the second half is the part that has no technical replacement: an audience already browsing. If your sales come from that marketplace, leaving costs you customers rather than saving you a fee. If your sales come from your own audience, the fee is pure overhead and this is straightforward.

STACK
- Node 20+ with Fastify, server-rendered HTML
- SQLite through better-sqlite3, WAL mode
- One payment provider, hosted checkout
- Caddy in front

WORK OUT THE ANSWER FIRST
- Look at where your buyers actually came from last month. If most arrived through the marketplace, the fee is customer acquisition and it is cheap
- If most came from your own posts, list or site, you are paying a percentage for payment processing you could have at a fraction of the cost
- Write that number down before writing any code. It is the whole decision

THE DATA MODEL
- products: id, slug, name, description_md, cover_path, kind, price_cents, currency, pricing_kind, is_active — a one-off, a subscription, or access to something
- customers: id, email, name, external_refs_json, created_at
- orders: id, customer_id, product_id, amount_cents, currency, tax_cents, tax_country, tax_evidence_json, provider_ref, status, created_at, refunded_at
- subscriptions: id, customer_id, product_id, provider_subscription_id, status, current_period_end, cancel_at
- entitlements: derived from orders and subscriptions, never a stored flag that drifts from what was paid for
- deliveries: id, order_id, kind, target, status, attempts, external_ref, at — what the purchase actually grants
- provider_events: id, event_id, kind, payload_json, processed_at — idempotency lives here

DELIVERING ACCESS, WHICH IS WHAT THESE PRODUCTS SELL
- The usual purchase is access to something elsewhere: a chat server, a private channel, a repository, a group
- So delivery is an adapter per target: grant on payment, revoke on refund or cancellation, and reconcile nightly so a lapsed subscription does not keep access for a month
- Idempotent by order id, retried with backoff, every attempt recorded. A grant that silently failed is a customer who paid and got nothing, and they will not write to you — they will charge back
- Revocation is the half everybody forgets. Build it first, and run the reconciliation from day one
- Where the target has no API, issue a single-use invite and record that it was used

PAYMENTS AND TAX
- Hosted checkout; the order is created from the verified webhook, never from the browser returning to a success page
- Idempotency by event id and out-of-order delivery handled
- For digital goods across borders the tax rate is usually the buyer's. Collect the country, apply the rate, and store two pieces of non-conflicting evidence of where they were. That evidence requirement is what people discover a year late — put it in the README and take advice
- You are the merchant of record now. Refunds, chargebacks and disputes are yours, and a chargeback costs the fee as well as the sale

THE STOREFRONT
- A product page and a checkout that is three fields, fast and server-rendered
- It must look trustworthy to somebody about to type a card number: a real name, no layout shift, a visible refund policy
- A customer's own page listing what they bought, their access, and how to cancel in two clicks
- Receipts that arrive, from your own domain with SPF, DKIM and DMARC configured — a missing receipt is a support message

FINDING BUYERS, WHICH IS NOW YOUR JOB
- Affiliate links with attribution and a hold period before a commission matures, if you want others selling for you
- An email list, with consent recorded, because that is the audience nobody can take away
- Say it plainly in the README: leaving a marketplace means owning distribution, and that is work rather than code

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SESSION_SECRET, SMTP_URL, PROVIDER_KEY, PROVIDER_WEBHOOK_SECRET, target credentials
- Migrations on boot, each once; reconcile nightly against the provider and the delivery targets
- Nightly backup off the machine — this holds customers and money
- Health endpoint checking the provider, mail and each delivery adapter

WHAT MATTERS MOST
Revocation and the reconciliation. Granting access on payment is easy; taking it back when a subscription lapses is what decides whether the business works.