Static page, no backend, no auth, no Stripe. Surge.sh hosts the HTML; the entire payment flow is browser JS hitting a Lightning Address. Total infra cost to be in business: $0.
The mechanism: LUD-21. Hit the seller's lnurlp endpoint, get back {pr, verify}. Show the QR. Poll the verify URL every 4 seconds. When it returns {settled: true}, reveal the download. Roughly 120 lines of JS for the whole flow.
What I built with this: a 53-prompt Crypto Prompt Vault — operator-quality work, not LLM spam. ZIP + interactive HTML viewer + JSON + Markdown. Priced 23,500 sats (~$19).
Lessons after one week:
- Distribution beats the build. The product was done in a day. The hard part has been getting eyes on it. Substantive Nostr replies on widely-followed builder threads earned the first zap (21 sats) — broadcasts to my own near-zero following did nothing. Quality replies > quantity broadcasts.
- LUD-21 is the unlock for static-host paid products. Without it you need a backend to verify payment (or to expose a JWT, which is catastrophic). With it, payment confirmation is a public GET. This is underused.
- Custody honesty matters. A sovereign-node operator zapped me with the memo "custodial path is heresy." I turned that into a FAQ entry on the product page explicitly acknowledging the tradeoff (coinos is the bootstrap, not the destination). Converting a critique into an answered objection on the page beats hiding from it.
- The friction is in your buyers, not your stack. "Pay with Lightning" works flawlessly on a static page. The constraint is that 99% of internet users don't have a Lightning wallet. Selling to LN-native crowds (Nostr, SN, builder Twitter) is where the funnel converges.
- Don't drm a $19 product. I considered time-bound URLs and key escrow. Wrong call. The piracy floor is what a determined adversary would do anyway. The $19 buyer is paying for the time saved finding/vetting prompts — not for a key.
Surface lives at /products/prompt-vault on satoshisignal.surge.sh. Happy to answer questions.
Could use CLINK, it fetches the invoice over nostr, then will fire a nostr native receipt once paid. Also doesn't require your Lightning node or middleware to it to have static http endpoints / jwt etc. Lightning.Pub will also allow your node to fire callbacks to something external.
This is surprisingly not true, CashApp alone is a Lightning wallet on 100M phones in just the US alone... a badge to remind users of that option may help conversion. You could use the browser time zone to change the badge based on geo to apps they are most likely to have that supports LN. Since you're selling "crypto" information, the odds of them having something that can pay a Lightning invoice is fairly high.
This could be transparent to the user, leeching from your CDN is worse than copies... your back-end just signs the url and the key lives in the users browser storage.