How to make your sign-in page look like your brand (and pass Google's checks)

When the Google authentication is done, you will have something genuinely lovely: pretty much a one-click sign-up. A person taps once, and they are in.

Now you move to the cosmetics, because that sign-up page is one of the first things a new user sees, and it has to reflect your brand, not look like a default template some robot dropped in. Name this part of the work properly when you brief the AI, describe the brand feel you want, and then ask it to verify the result against what you asked for. If you have obeyed the rules, this should not take long.

And there are rules. Google does not just let any random site hold its users' login. To pass, you will usually need a Terms of Service document and a Privacy and Security document actually living on your site, and the name of your platform, exactly as you have called it, present on your home page. These are not bureaucratic annoyances. They are the price of being trusted with people's identities, and frankly you wanted those documents anyway.

The door is the first handshake. Make it look like you, and make it honest enough that the gatekeepers trust you with their people.

The second door: email, password, and the token thing nobody tells you about

Not everyone will want to use Google. So for the second method, you let people simply use their email address and choose a password. Classic front door.

Here is where I need you to pay attention to one quiet, unglamorous thing that matters more than almost anything else on this page. Make sure Supabase is rotating your users' tokens — the credentials that keep them logged in. One of the big reasons I love Supabase is that I believe this is their default behaviour. You do not have to be clever to be safe; the platform is being safe on your behalf.

And let me hand you a small thesis for free while we are here:

The brands that default to keeping newbies safe, that protect you before you even know to ask, are the ones that will see a lot of profit in the near future.

Because the next wave of builders are people like me. Non-technical, ambitious, and reliant on good defaults. Whoever protects us by default earns us for life.

How to send confirmation emails from your app

Both of these doors need to send letters. Confirmation emails. Verification links. The "is this really you" messages. For that, your platform needs a way to actually send email, and that means an email sender service that gives you the SMTP details Supabase needs to send messages to your users.

There is a free version built in for testing, and I want to set your expectations honestly: it is deliberately tiny, something like two emails every three hours, or some equally silly number. That is fine. It exists so you can confirm the plumbing works, not so you can launch to the world.

The moment you want to test with many people, you graduate to a proper sender. I used Resend, and I got an email domain for my site. A small warning from my own scars: Resend can sometimes require that email domain before it lets you in. It actually rejected me once, then let me in on a second go, maybe because I came in through my GitHub account — I genuinely am not sure. The lesson is just: do not panic if it bounces you the first time, and get yourself an email address that matches your domain, because you will need it regardless.

Once you are set up, Resend gives you around three thousand free emails. Sit with that. Your first three thousand users are essentially covered for free.

Why a "forgot password" flow is a growth feature, not a nice-to-have

Before you celebrate those three thousand emails, this is the perfect moment for me to beg you to do one thing: code in a "forgot password" feature.

People will forget. They always forget. And here is why it actually matters for your growth, with real numbers. Say a thousand users forget their password in a month. With a forgot-password flow eating into your free allowance, you still have two thousand emails left over for brand-new users that month. That is not a leak in your bucket — that is a perfectly healthy growth rate running entirely on free infrastructure.

And if you are growing faster than that? Wonderful problem. About twenty dollars gets you something like fifty thousand emails. (Check the current pricing before you quote it from a stage like I am; these plans move.) And if you somehow need more than fifty thousand emails a month, then my friend, it is time to call a VC, because you have a real thing now and you need funds too.

The mechanics, as always, are simple. Grab your key from Resend, take it to Claude, and ask it to set up the system for you. It will do it. And then you test. And it works.

Congratulations. You are now back to exactly where you were inside Base44, with people signing up and signing in. Except this time you are independent, you own everything, and you are no longer stuck in traffic. You are on the freeway.

Hands-on lab

The chapter above is the why. These guides are the how. The one rule never changes: if a step stumps you, screenshot it and paste it to your AI with "assume I have no technical experience; tell me exactly what to click next." Nothing here cannot be undone.

G3.1 · Set up "Sign in with Google" (Google OAuth) [Core]

What you'll have: One-tap Google sign-in for your users.

Before you start: Beginner–Intermediate · ~30 min · free · you'll need a live domain, Supabase, a Google account

1. Go to the Google Cloud Console (console.cloud.google.com). Note: this is the OAuth console, different from Google Search Console.
2. Create a project (it has its own help; lean on it).
3. Configure the OAuth consent screen: app name, support email, domain, and links to your privacy and terms pages (G3.2).
4. Create OAuth credentials for a web app; add your domain and Supabase's callback URL as authorised redirect URIs (Supabase shows this URL in its Authentication settings).
5. Copy the Client ID and secret into Supabase → Authentication → Providers → Google.
6. Test the Google sign-in on your site.

Check you did it right: You can sign in with Google end to end.

If something looks off: "redirect_uri_mismatch" → the redirect URL in Google must match Supabase's exactly. Screenshot and ask.

G3.2 · Prepare your OAuth requirements and brand the sign-in screen [Core]

What you'll have: A sign-in that looks like your brand and passes Google's checks.

Before you start: Beginner · 1–2 hrs · free · you'll need your brand plus terms and privacy docs

1. Create a Terms of Service page and a Privacy and Security page and publish them on your site. Ask Claude for drafts, then have a person (ideally a lawyer for your jurisdiction) review them.
2. Make sure your platform's name appears on your home page.
3. Add your app name, logo, domain, and those page links to the Google consent screen.
4. Ask Claude to style the sign-up and sign-in pages to your brand, then "verify it matches the brand brief."

Check you did it right: The consent screen shows your name and logo; your legal pages are live and linked.

If something looks off: Verification pending → sensitive scopes can take time; basic scopes are fine to start.

G3.3 · Add email and password sign-up in Supabase [Core]

What you'll have: A classic email and password door for users who do not want Google.

Before you start: Beginner · ~20 min · free · you'll need your Supabase project

1. In Supabase → Authentication → Providers, make sure Email is enabled.
2. Set sign-up options; keep email confirmation on once sending works (G3.5).
3. Ask Claude to build the sign-up and login UI wired to Supabase auth.
4. Test creating an account with an email and password.

Check you did it right: You can register and log in with email and password.

If something looks off: Confirmation emails not arriving → you need an email sender first (G3.5).

G3.4 · Confirm Supabase is rotating your tokens [Core]

What you'll have: Peace of mind that logged-in sessions are handled securely by default.

Before you start: Beginner · ~10 min · free · you'll need Supabase auth on

1. In Supabase → Authentication settings, review session and refresh-token settings.
2. Confirm refresh-token rotation is enabled (Supabase's secure default) and set a sensible session expiry.
3. Ask Claude: "Confirm my Supabase auth uses refresh-token rotation and short-lived access tokens, and flag anything insecure."

Check you did it right: Token rotation is on and Claude confirms no obvious auth weaknesses.

If something looks off: Unsure what you are seeing → screenshot the auth settings to Claude and ask plainly.

G3.5 · Connect an email sender (Resend) and verify your domain [Core]

What you'll have: Your app able to send confirmation, verification, and reset emails reliably.

Before you start: Beginner–Intermediate · 30–45 min · free up to ~3,000 emails/mo; ~$20/mo for ~50,000 (check current) · you'll need your domain

1. Know that Supabase's built-in email is rate-limited to a trickle — fine for testing only.
2. Create a Resend account (signing up via GitHub can smooth approval).
3. Add and verify your sending domain in Resend by adding DNS records at your registrar; set up an email address on your domain.
4. Copy your Resend API key.
5. In Supabase → Authentication → SMTP settings, plug in Resend's details, or hand the key to Claude: "set up Resend as my email sender for Supabase auth emails."
6. Send a test email.

Check you did it right: A real confirmation or test email lands in an inbox.

If something looks off: Resend rejected you → it sometimes needs a verified domain; verify and try again. Emails go to spam → finish domain verification (SPF/DKIM records).

G3.6 · Add a "forgot password" flow [Core]

What you'll have: Users can reset forgotten passwords themselves.

Before you start: Beginner · ~30 min · free (uses your email sender) · you'll need G3.5 working

1. Ask Claude to add a forgot-password flow using Supabase's password reset.
2. It sends a reset link via your Resend email.
3. Build the page where users set a new password.
4. Test the full loop: request reset, receive email, set a new password, log in.

Check you did it right: You can reset a password end to end.

If something looks off: Reset email not arriving → check G3.5 and spam.

Move as an ecosystem, not a thousand solo founders

Notice how much of tonight was numbers. Three thousand free emails. Twenty-five dollars. Twenty dollars for fifty thousand. The barriers are now small, but they are not zero, and they land hardest on the person starting out with empty pockets and a full imagination. That is exactly the person I used to be.

So learn this, and then refuse to do it alone. Africa has to move as an ecosystem, not a thousand solo founders each paying for the same things separately and quietly giving up when the small costs stack. Some of us share hosting. Some share tokens, keys, and the hard-won knowledge of which service rejected us and why.

That is what the AIStoryLab community is for: plain-language guides to every term I have thrown at you, the how-tos for every step, and resources donated by other builders who walked this exact road — so the door you are trying to walk through is never one you face by yourself.

What's next

Here is your cliffhanger. Why is your platform saving and serving images as JPEG? Why is your platform using people's email addresses to identify them — and worse, why is that email showing on the front page for anyone to see? You built a working thing. Next we make it a good thing: the unglamorous part, where we test everything by hand and optimise until the platform is fast, lean and cheap to run.