Non-custodial is the right call, both for your users' safety and your own legal exposure. Here's the shortest path to a weekend demo:

Stack that gets you there fastest:

• BTCPay Server (self-hosted, free) as the payment engine — it gives you on-chain + Lightning invoices out of the box, and its Greenfield API lets your frontend create invoices per campaign without you ever holding keys.
• LNURL-pay static addresses for recurring/supporter flows — each campaign can have campaign@yourdomain via a tiny LNURL server or BTCPay's built-in Lightning address support.
• Frontend: any static host (Cloudflare Pages/Vercel) + a JSON file per campaign. Don't build a database until you have users.

Non-custodial patterns worth studying:

• Geyser Fund and Zaps (zaps256) are exactly this model — look at how they route funds straight to campaign wallets.
• For sanctions-affected regions specifically, Lightning beats on-chain for small amounts: instant, near-zero fees, and receivers only need a wallet like Phoenix/Blixt, no exchange KYC.

Honest warnings from someone who builds these:

1. "Non-custodial" legally protects you less than people assume if you curate campaigns — talk to a lawyer about OFAC/sanctions exposure before launch, not after. This is genuinely the riskiest part of your idea, not the code.
2. The hard problem isn't payments, it's trust and verification of recipients in low-connectivity regions. The Anita thread above nails it: proof-of-work and reputation first.
3. Vibecoding the frontend + hiring a dev for payment plumbing is the right split. The plumbing (invoice webhooks, refund handling, key management) is where money bugs live.

Happy to review architecture or help wire up the BTCPay integration if useful — this space needs working examples.