claude-code·7 min read·
Supabase auth + Stripe billing for a UK SaaS (Claude Code, 2026)
Your skeleton is live. Now your founding members need two things: a way to log in and a way to keep paying you. This is the UK indie hacker walkthrough for wiring Supabase auth and Stripe subscriptions with Claude Code - the auth flow, the subscription model, the one webhook that actually matters, and the UK-specific decision every US tutorial skips: do you take payments through Stripe directly and own your VAT, or go through a Merchant of Record like Paddle and hand the VAT headache away?
Your skeleton is live on Vercel. You scaffolded it in one session and sent the URL to a founding member who has already paid you in pounds. Good. Now that founding member needs two things before the product is real: a way to log in, and a way to keep paying.
This is the part of the build where UK indie hackers either move fast and get it right, or spend a fortnight reinventing auth and then discover their billing is a security hole. Claude Code makes the happy path quick. The job here is to make sure you point it at the right pattern - and to make the one UK-specific decision that every US tutorial quietly ignores.
Auth: use Supabase, do not build it
Building your own auth is the canonical example of solving a problem nobody is paying you to solve. Supabase ships it: email/password, magic links, OAuth with Google and GitHub, sessions, password resets, email verification - all handled.
For a small founding cohort, the lowest-friction choice is magic links as the primary flow. No passwords to forget, no reset emails to build, one click from inbox to logged in. Ask Claude Code to wire it.
But the part that actually matters for a product holding paying customers' data is row-level security. Supabase auth integrates with Postgres row-level security, which means who-can-see-what is enforced at the database layer, not in your app code. This is the difference between a misconfigured auth check being a UI bug and being a data leak. App-code checks fail open when you forget one; row-level security fails closed.
So the instruction to the agent is two-part:
Wire Supabase auth with magic links as the primary flow. Set up row-level security policies on every table from the start, defaulting to deny, so a user can only read and write their own rows.
Do not let it hand-roll JWT handling, session storage, or password hashing. That road leads to an incident, not a product. The temptation is real because a coding agent will happily build you a bespoke auth system that looks like it works in a demo - and a bespoke auth system that looks like it works is precisely how data leaks happen. Auth is a solved problem with a hardened, audited implementation one import away; spending your finite v1 effort there is spending it in the one place where "good enough" is genuinely dangerous. If you want the deeper Supabase-versus-alternatives reasoning, the Supabase vs Neon comparison covers why Supabase's bundled auth tips the decision for solo founders.
Billing: the minimum Stripe setup that works
Stripe's surface area is enormous. For a v1 you need a small corner of it:
- One Product, one recurring Price, in GBP. The number you validated when you pre-sold founding members.
- Stripe Checkout to take the payment - a hosted page, no card forms to build or secure.
- The Customer Portal so people can update cards, change plans, or cancel without emailing you.
- One webhook - and this is the one thing you must get right.
The one webhook that matters
The critical event is the subscription-status webhook: created, updated, deleted. When Stripe says a subscription went active, past_due, or cancelled, your handler writes that status to the user's row in Supabase. Your app then reads that single field to decide what the user can access.
The classic indie-hacker billing bug is reading subscription state from the client, or trusting the checkout success redirect. Both are spoofable and both drift out of sync. The webhook is the only source of truth Stripe controls, so it is the only one you trust.
Build it first, before the pretty pricing page. Tell Claude Code:
Build the Stripe subscription webhook handler first. Verify the signature, make it idempotent, and on subscription created/updated/deleted write the status to the user's row in Supabase. Then we will build the pricing page.
Test it with the Stripe CLI forwarding events to your local handler and Stripe's test clock for renewals. The happy path is fast; the care goes into signature verification and idempotency so a replayed event does not corrupt state.
The UK decision US tutorials skip: who handles your VAT
Here is the fork no boilerplate makes for you, and it is genuinely a UK indie hacker's call.
Option A - Stripe direct. You are the merchant. Stripe is cheap (roughly 1.5 percent plus 20p for UK cards) and you own the customer relationship. But you are responsible for VAT: charging the right rate to UK and EU customers, filing it, and watching the threshold. UK VAT registration becomes compulsory above 90,000 pounds of taxable turnover - below that you can choose to stay unregistered and not charge VAT at all, which keeps things simple while you are small.
Option B - Merchant of Record (Paddle or Lemon Squeezy). They become the legal seller. They take a bigger cut (typically around 5 percent plus fees) but in exchange they calculate, collect, and remit VAT and sales tax worldwide, and they issue the invoices. For a UK founder selling globally with no finance function, that fee is often worth it precisely because it deletes the cross-border VAT problem at the moment you are least equipped to handle it.
The rough rule:
- UK-only, comfortably under 90k, want the lowest fees: Stripe direct.
- Selling globally, or you simply never want to think about VAT: Merchant of Record.
Decide before you wire it. Switching later means re-plumbing billing, and that is a job you do not want twice. If you are still on the wider payments question, the Stripe vs PayPal vs GoCardless breakdown sits one level up from this decision.
Gating features without making a mess
You now have auth and billing. The last piece is letting them talk: paying users get the product, non-paying users get the upsell.
Do it with one field and one source of truth:
- The verified webhook writes
subscription_statusto the user's row in Supabase. Nothing else writes it. - Your app reads that one field everywhere it gates a feature.
- Encode the gate in row-level security too, so a non-paying user physically cannot query premium rows even if your UI has a bug.
Do not scatter live Stripe API calls through your app asking "is this user paying" on every request - it is slow, rate-limited, and fragile. One place the status can be wrong (the webhook), one place it is read (a single helper plus the row-level security policy). When billing misbehaves, you know exactly where to look.
Tell Claude Code to centralise the check rather than sprinkling conditionals, and to add the premium-row policies to the database, not just the UI.
Test the money path before you trust it
Auth bugs annoy users; billing bugs lose money or, worse, charge people wrongly. So the billing path gets the one piece of real testing in your v1.
Three things to actually exercise before a founding member's card goes near it:
- A full checkout in Stripe test mode. Use Stripe's test cards, run a subscription through Checkout, and confirm the webhook fires and writes
activeto the right user's row in Supabase. Watch it happen end to end, do not assume it. - A cancellation. Cancel through the Customer Portal and confirm the webhook flips the status and your app correctly downgrades access. Cancellation is the path people forget to test, and a customer who cancels but keeps full access is a silent revenue leak.
- A replayed event. Stripe can deliver the same webhook twice. Fire the same event at your handler twice and confirm the second one does not corrupt state - that is what idempotency buys you, and it is cheap to verify.
Claude Code can write a short script or a checklist to drive these with the Stripe CLI. The point is not exhaustive coverage; it is proving the money path is sound on the three flows that matter. Everything else you can fix live. Billing, you get right before launch.
How long this takes, and what to leave out
A focused day, sometimes an afternoon, if your skeleton is deployed and your CLAUDE.md documents the stack. Auth is the fast half; the Stripe webhook is where the care goes.
The honest time sink is not the happy path - it is imagining every billing edge case. Failed payments, mid-period cancellations, expiring cards, proration, dunning. For v1, handle active versus not-active cleanly and leave the rest. Your three founding members will not hit most of those edge cases, and you will learn which ones actually matter from real usage rather than from a worried afternoon inventing them.
Ship the version that lets a founding member log in and pay. Iterate the edge cases when a real one shows up.
Next: the go-live checklist that gets your v1 into your founding members' hands and sets up the feedback loop that keeps them.
Building your validated idea? IdeaStack publishes one deeply-researched, UK-specific business opportunity every week - real keyword volumes, competitor analysis, SERP landscape, and copy-paste builder prompts. Read this week's free report and find the next idea worth building.
Frequently asked
Should I build the auth flow myself or use Supabase's built-in auth?
Use Supabase auth - building your own is the textbook example of solving a problem nobody is paying you to solve. Supabase ships email/password, magic links, and OAuth providers (Google, GitHub) out of the box, with sessions, password resets, and email verification handled, and it integrates with row-level security so your database enforces who-can-see-what at the data layer rather than relying on your app code to remember. For a v1 you are handing to paying founding members, that last point is the one that matters: a misconfigured auth check in app code is a data leak, whereas row-level security fails closed. Ask Claude Code to wire Supabase auth with magic links as the primary flow (lowest friction for a small founding cohort) and to set up row-level security policies on every table from the start. Do not hand-roll JWT handling, session storage, or password hashing - that road leads to a security incident, not a product.
What is the minimum Stripe setup for recurring GBP subscriptions, and which webhook actually matters?
The minimum is one Product with one recurring Price in GBP, Stripe Checkout to take the payment, the Customer Portal so people can manage or cancel without emailing you, and exactly one webhook you must get right: the one that tells your database whether a user's subscription is active. Everything else in Stripe's enormous surface area is optional for v1. The critical webhook is the subscription-status event (created, updated, deleted) - when Stripe says a subscription went active, past_due, or cancelled, your handler writes that status to the user's row in Supabase, and your app reads that single field to decide what the user can access. The classic indie-hacker billing bug is reading subscription state from the client or trusting the checkout redirect - the webhook is the only source of truth Stripe controls, so it is the only one you trust. Ask Claude Code to build the webhook handler first, verify the signature, and write the status to Supabase; build the pretty pricing page second.
Do I take payments through Stripe directly or use a Merchant of Record like Paddle or Lemon Squeezy?
This is the UK-specific decision most tutorials skip, and it comes down to who handles VAT. With Stripe direct, you are the merchant - you collect payments cheaply and own the relationship, but you are responsible for charging the right VAT to UK and EU customers, filing it, and tracking thresholds (UK VAT registration becomes compulsory above 90,000 pounds of taxable turnover). With a Merchant of Record like Paddle or Lemon Squeezy, they are the legal seller - they take a higher cut (typically 5 percent plus fees versus Stripe's roughly 1.5 percent plus 20p for UK cards) but they calculate, collect, and remit VAT and sales tax worldwide on your behalf, and they handle the invoices. For a UK indie hacker with a handful of founding members and global ambitions, the Merchant of Record fee is often worth it precisely because it removes the cross-border VAT compliance burden at the exact moment you have no finance function. For a UK-only product staying well under the VAT threshold, Stripe direct is cheaper and simpler. Decide before you wire it, because switching later means re-plumbing your billing.
How do I gate features by subscription status without making a mess of my code?
Store a single source-of-truth subscription field on the user's row in Supabase, written only by your verified Stripe webhook, and check that one field everywhere you gate. Do not scatter Stripe API calls through your app to ask 'is this user paying' on every request - that is slow, rate-limited, and fragile. The webhook writes the status (active, trialing, past_due, cancelled) to Supabase; your app reads it. For the data layer, encode the gate in row-level security policies so a non-paying user physically cannot query premium rows even if your UI has a bug. For the UI layer, a single helper that reads the status field keeps the logic in one place. This pattern means there is exactly one place subscription state can be wrong - the webhook - and one place it is read, so when billing misbehaves you know where to look. Ask Claude Code to centralise the check rather than letting it sprinkle conditionals.
How long should wiring auth and billing actually take with Claude Code?
A focused day, sometimes an afternoon, if your skeleton is already deployed and your CLAUDE.md documents the stack. Supabase auth with magic links and row-level security is a well-trodden path the agent handles cleanly; the Stripe side takes the longer share because the webhook needs care - signature verification, idempotency, writing status to Supabase, and testing with Stripe's test clock and CLI event forwarding. The honest time sink is not the happy path, which is fast, but the edge cases: what happens on a failed payment, on a cancellation mid-period, on a card that expires. For v1 you handle active versus not-active cleanly and leave dunning and proration for later - that keeps the build to a day. Resist the urge to handle every billing edge case before launch; your three founding members will not hit most of them, and you will learn which ones matter from real usage rather than from imagining them.
