How to Add Authentication to Your AI-Built SaaS (UK Guide)

You have built something. Maybe you used Claude Code to scaffold the backend, or Lovable to spin up the frontend. It works. It looks decent. You showed it to three people and they said "yeah, I would pay for that."

And then someone asks: "How do I log in?"

Authentication is the first real piece of production infrastructure your SaaS needs. It is also the part where most solo builders lose a week, get frustrated, and end up with something fragile. That does not have to be you.

This guide walks through adding auth to an AI-built SaaS, specifically for UK builders who need to think about GDPR from day one. We will cover two practical options -- Supabase Auth and Clerk -- and help you pick the right one for your project.

Why Authentication Matters More Than You Think

Authentication is not just "letting people log in." It is the foundation for:

• Billing: You cannot charge someone without knowing who they are
• Data isolation: User A must never see User B's data
• GDPR compliance: You need to know who owns what data so you can delete it on request
• Trust: A login screen with social sign-in signals "this is a real product"

If you skip auth or bodge it, you will hit a wall the moment you try to add payments, teams, or any feature that requires knowing who the user is.

Option 1: Supabase Auth (Best for Most AI-Built Projects)

If you built your backend with Supabase -- which is increasingly common for AI-built SaaS -- then Supabase Auth is the obvious choice. It is already there. You just need to turn it on.

Why Supabase Auth Works for UK Builders

• Free tier covers most MVPs: Up to 50,000 monthly active users on the free plan. You are not paying for auth until you have a real business
• EU hosting available: Supabase lets you create projects in the EU region (Frankfurt or London). This matters for GDPR -- your user data stays in Europe
• Row-Level Security (RLS): Supabase's killer feature. You write policies that automatically ensure users can only access their own data. No more "oops, User A can see User B's dashboard"
• Built-in social login: Google, GitHub, Apple, Microsoft -- all pre-configured. UK users expect Google sign-in at minimum

How to Set It Up

Step 1: Enable auth providers in Supabase Dashboard

Go to Authentication > Providers in your Supabase project. Enable Email/Password (the baseline) and Google OAuth (the one your users will actually use).

For Google OAuth, you will need to create OAuth credentials in Google Cloud Console. Set the redirect URL to your Supabase project's callback URL. This takes about 10 minutes.

Step 2: Install the Supabase client

If you are using Claude Code, you can literally say: "Add Supabase Auth to this Next.js app. I want email/password and Google sign-in. My Supabase URL is X and anon key is Y."

Claude Code will scaffold the auth context, sign-in page, sign-up page, and protected route middleware. It is remarkably good at this because Supabase's patterns are well-documented and consistent.

Step 3: Add Row-Level Security policies

This is the part most tutorials skip, and it is the most important part for a production SaaS. For every table that contains user data, you need an RLS policy.

A basic policy looks like this: "Users can only SELECT rows where the user_id column matches their auth.uid()." Claude Code can generate these policies for you -- just describe your data model and ask it to write RLS policies.

Step 4: Handle the session on the server

If you are using Next.js (which most Lovable and Claude Code projects default to), you need server-side session handling. This means using Supabase's SSR helpers to read the session from cookies in your middleware and Server Components.

The key pattern: create a Supabase client that reads the session from cookies on the server, and a separate client that manages the session in the browser. Claude Code handles this well if you tell it you want "server-side auth with Supabase SSR helpers."

GDPR Considerations with Supabase Auth

• Data location: Create your Supabase project in the EU region. This is a one-time choice at project creation -- you cannot move it later
• Data deletion: Supabase provides an API to delete users (supabase.auth.admin.deleteUser()). You must also cascade-delete their data from all tables. Write a "delete my account" function early
• Cookie consent: Supabase Auth uses essential cookies for session management. These do not require consent under GDPR (they are strictly necessary). But if you add analytics cookies, you will need a consent banner
• Privacy policy: You need one. It must explain what data you collect (email, name if using social login), why (to provide the service), and how users can request deletion. You can ask Claude Code to draft one based on your data model

Option 2: Clerk (Best for Teams and Complex Auth)

Clerk is a dedicated auth provider that handles everything from sign-in forms to user management dashboards. It is more opinionated than Supabase Auth but significantly faster to implement if you need features like team management, role-based access, or multi-factor authentication.

Why Clerk Works for UK Builders

• Pre-built UI components: Drop-in sign-in and sign-up forms that look professional out of the box. No designing auth screens
• Team/organisation support: If your SaaS has workspaces or team accounts, Clerk handles invitations, roles, and permissions natively
• GDPR-ready: Clerk offers EU data residency and has a Data Processing Agreement (DPA) available. They handle consent collection for their components
• Fast integration with Next.js: Clerk's Next.js SDK is mature. Middleware-based auth protection works out of the box

How to Set It Up

Step 1: Create a Clerk application

Sign up at clerk.com and create an application. Choose your sign-in methods (email, Google, GitHub, etc.). Clerk gives you publishable and secret keys immediately.

Step 2: Install and configure

Install @clerk/nextjs and add your keys to .env.local. Wrap your app in ClerkProvider. Add the middleware file to protect routes.

If you are using Claude Code, say: "Add Clerk authentication to this Next.js app. I want Google sign-in and email/password. Here are my Clerk keys." Claude Code will scaffold the provider, middleware, and protected routes.

Step 3: Use Clerk's components

Drop <SignIn /> and <SignUp /> components into your pages. They handle the entire flow -- form validation, social login buttons, error states, loading states. You do not need to build any of this.

Step 4: Access user data in your API

Use currentUser() in Server Components or auth() in API routes to get the authenticated user. Clerk provides the user ID, email, and profile data.

When to Choose Clerk Over Supabase Auth

• Your SaaS has team/workspace functionality
• You want pre-built UI components and do not want to design auth screens
• You need advanced features like multi-factor auth, device management, or session revocation
• You are willing to pay (Clerk's free tier is 10,000 monthly active users -- generous but lower than Supabase's 50,000)

The GDPR Checklist for UK SaaS Auth

Regardless of which auth provider you choose, you need to handle these GDPR requirements. The UK operates under UK GDPR (retained from EU GDPR post-Brexit), and the rules are essentially identical.

Must-Have from Day One

1. Privacy policy: Explain what data you collect, why, how long you keep it, and how users can request deletion. Link to it from your sign-up page
2. Data deletion endpoint: Build a "delete my account" function that removes the user from your auth provider AND all their data from your database. Test it
3. EU/UK data storage: Host your database in the EU or UK. Both Supabase (Frankfurt/London) and Clerk (EU residency) support this
4. No unnecessary data collection: Only collect what you need. If you do not need a phone number, do not ask for one
5. Secure session handling: Use HTTPS everywhere (Vercel handles this), secure cookies, and proper CORS settings

Nice-to-Have (But Do Them Soon)

1. Data export: Users should be able to download their data. Build an export endpoint
2. Cookie banner: Only needed if you use non-essential cookies (analytics, tracking). Auth cookies are exempt
3. DPA with your auth provider: Both Supabase and Clerk offer Data Processing Agreements. Sign one
4. Breach notification plan: If user data is compromised, you have 72 hours to notify the ICO. Have a plan (even if it is just "email Tim")

Common Mistakes UK Builders Make with Auth

Mistake 1: Building Auth from Scratch

Do not build your own auth. You will get it wrong. Password hashing, session management, CSRF protection, rate limiting, email verification -- there are dozens of edge cases that auth providers have already solved. Use Supabase Auth or Clerk.

Mistake 2: Storing Passwords in Plain Text (Yes, This Still Happens)

If you asked Claude Code to "add a simple login" without specifying an auth provider, it might scaffold a basic username/password table. This is not production auth. Always use a dedicated auth provider.

Mistake 3: Forgetting About the Delete Path

GDPR gives users the right to delete their data. If you cannot delete a user's account and all associated data, you are non-compliant from day one. Build the delete path when you build the create path.

Mistake 4: Ignoring Row-Level Security

If you are using Supabase, RLS is your best friend. Without it, any authenticated user can potentially read any other user's data through your API. Enable RLS on every table and write explicit policies.

Mistake 5: Not Testing the Auth Flow

Sign up. Log in. Log out. Reset password. Delete account. Do all five before you ship. You would be surprised how many AI-built projects break on "reset password" because nobody tested it.

Which Auth Provider Should You Choose?

Here is a simple decision tree:

• Using Supabase for your database? Use Supabase Auth. It is already integrated, free, and handles RLS natively
• Building a team/workspace product? Use Clerk. Its organisation and role management saves you weeks of development
• Need pre-built UI components? Use Clerk. Its sign-in/sign-up forms are production-ready
• Want maximum control? Use Supabase Auth. You own the user table and can extend it however you like
• Budget-conscious? Use Supabase Auth (50,000 MAUs free vs Clerk's 10,000)

For most solo UK builders shipping an MVP, Supabase Auth is the better starting point. It is free, it is already in your stack if you used Supabase, and it handles GDPR basics with EU hosting. You can always migrate to Clerk later if you need team features.

Putting It All Together

Here is the practical workflow for a UK builder adding auth to an AI-built SaaS:

1. Choose your provider -- Supabase Auth for most, Clerk for team products
2. Set up EU hosting -- Create your Supabase project in London/Frankfurt, or enable EU residency in Clerk
3. Use Claude Code to scaffold -- Tell it your auth provider, desired sign-in methods, and data model. It will generate 80% of the code
4. Add RLS policies (if Supabase) -- Protect every user-data table
5. Build the delete path -- Account deletion from day one
6. Write a privacy policy -- Claude Code can draft one based on your data model
7. Test the full flow -- Sign up, log in, log out, reset password, delete account
8. Ship it -- Deploy to Vercel. Your SaaS now has production auth

The whole process takes 2-4 hours with AI tools. Without them, it would take 2-4 days. That is the leverage.

Key Takeaways

• Supabase Auth is the best default choice for most AI-built SaaS projects -- it is free up to 50,000 users and integrates natively with your Supabase database
• Clerk is better when you need team/workspace features, pre-built UI components, or advanced auth like multi-factor authentication
• GDPR compliance starts at auth -- host in the EU/UK, build account deletion from day one, and write a privacy policy before you launch
• Row-Level Security in Supabase is non-negotiable for production SaaS -- it prevents users from accessing each other's data at the database level
• Use Claude Code to scaffold auth infrastructure -- it handles 80% of the boilerplate, but always test the full sign-up to deletion flow manually