Don't Let Claude Hand-Roll Auth and Billing

A guard rail for AI-assisted SaaS builds: for the security- and money-critical parts — authentication, session management, password handling, payments — use a proven provider or library and have Claude write the integration, rather than letting it generate a bespoke implementation from scratch.

Auth and billing are the parts of a SaaS where mistakes are worst and least visible: a subtly wrong session check or a mishandled webhook doesn't fail loudly, it just leaves a hole. Claude can generate plausible custom auth, but 'plausible' is exactly the danger — these domains are full of edge cases (token expiry, replay, race conditions, PCI scope) that established providers have already solved and hardened. Directing Claude to integrate a battle-tested provider instead means the risky core is code that thousands of apps have stress-tested, and Claude does what it's genuinely good at: wiring a documented API into your app.

Whenever a build reaches authentication, authorization, password or session handling, or taking payments. The instinct to 'just have Claude build a login' is the exact moment to stop and reach for a provider instead.

Prototypes with no real users or real money, where a throwaway stub is fine and nothing sensitive is at stake. And bespoke authorization logic on top of a proven auth provider is normal — the rule is against hand-rolling the cryptographic and protocol-level core, not against having any custom rules.

I'm adding <auth / payments> to this SaaS. Don't build a custom implementation — recommend a proven provider or library suited to my stack (<stack>), explain the trade-offs, and then write the integration against its official SDK/API. Call out the security-sensitive steps (token handling, webhook verification, secret storage) and how the provider expects them done.

Instead of accepting a hand-written JWT login flow, you have Claude integrate an established auth provider — it wires up the SDK, the callback, and session handling per the provider's docs. When you add payments, it integrates Stripe and, crucially, implements webhook signature verification the way Stripe requires. The sensitive core is proven infrastructure; Claude's job was the glue, which it does reliably.

Even with a provider, have Claude write tests around the integration's failure modes — expired tokens, invalid webhooks, declined payments — since those are where integration bugs hide. And keep secrets out of the code Claude generates: confirm it reads keys from environment/secret storage, never inlines them, and never logs them.

• Accepting custom auth or crypto because it 'works' in a demo — working and secure are different, and the gap is invisible.
• Letting Claude inline API keys or secrets into generated code instead of reading them from a secret store.
• Skipping webhook signature verification on payments because the happy path works without it — that's the security hole.