Why Your App Login Works in Preview but Breaks After You Publish

Written by: Vladislav Zhirnov
Published: September 13, 2026
Reading time: 13 min read
Topics: #Supabase
#MVP Development

You sign in while testing your app. You publish it, open the public address, and the same button sends you somewhere else. Or you reach your account, reload the page, and find yourself signed out.

Start by finding what changed. Replacing the login code before you know which step failed gives you more moving parts to untangle. Have AI inspect one attempt on the public site, name the cause, and repair that part.

This guide is for an existing Next.js app that uses Supabase to manage accounts. Your test version already signs people in. You will give AI the two app addresses and the sign-in method to check, then work through four prompts in order.

If signup and login still need setting up in both versions, start with the account-setup guide first.

Step 01Check the published version

Use the address you would send a customer. A fresh preview can contain your latest fix while the public address still opens an older version. Until AI checks what is running at that address, it can end up fixing code your users never reach.

Give it the working test address too, or access to the app running on your computer. The comparison needs three things: which version each address opens, which Supabase project each uses, and where each sends people after sign-in. A different project may be intentional. AI needs to establish what you meant to publish before calling a difference a mistake.

The settings for your public app can differ from those used in testing. If Vercel runs your app, these groups are called Production and Preview. Vercel lets each group have its own settings (opens in a new tab). A value saved for Preview therefore does not show what the public app received.

You do not need to hunt through every settings page yourself. AI can inspect the app, check its installed tools, and use the service connections you have allowed. If it lacks access, it should help you connect the relevant service. An account login or access grant may need you; the inspection can continue afterward.

If the public app does not load at all, deal with that publishing problem first. A missing site or the hosting service's access screen is a different starting point from your app rejecting a sign-in.

Check what the public address is running

This first prompt gives AI a concrete comparison before it changes anything. Replace the bracketed details. Use one app account made for testing, so the later checks have an account and expected page to follow.

My app signs people in during testing, but sign-in fails after publishing.

Public app: [address customers open]
Working test version: [preview address, or the app on my computer]
Sign-in method to check: [Google, email code, or existing method]
What I see: [one sentence describing the failure]
Test app account: [identify the test account through the connected app; do not paste a password or code]

Inspect my existing app and the available, authorized service connections. Confirm which app version each address opens, the intended Supabase project for each, and the addresses used to return after sign-in. Compare the settings actually used by those versions. Explain intentional differences separately from suspected mistakes.

Do this inspection without changing code or service settings. Keep secrets and account details out of your report. If access is missing, help establish the supported connection and ask me only for the specific access or identity action you need. Then continue.

Return a short comparison of the working and public versions. Mark anything you could not verify. If the public app itself cannot load, identify that problem before diagnosing login.

After you run it: Check that the report names your real public address and the version running there. It should say whether both versions use the intended account service. If it only describes files on your computer, the public version still needs checking.

Step 02Find where sign-in stops

Now follow one new attempt from the public address. The useful question is what worked immediately before it stopped. Seeing the Google account picker proves you reached Google. Seeing your app again proves you returned. Neither observation, by itself, shows that your app has recognized the right account.

When Google sign-in takes you away from your app through Supabase, there are two return trips. Google sends the result to Supabase, then Supabase sends you back to the app. The addresses receiving those returns are called callbacks. Supabase documents these two separate destinations (opens in a new tab). AI must compare the address on the failed trip with the setting for that trip.

A typed email code takes a different path. First check whether Supabase accepted it. If it did, investigate what your app did with that success. Supabase's email-code handling (opens in a new tab) does not automatically need the same return-page repair as Google sign-in.

Use the result you can see to choose the next check. Each row starts from a different stopping point; you do not need to work through them all.

What happens	What AI should check next
The sign-in button or Google rejects the attempt.	Find the actual error. Check the service or return address that was rejected before changing the app's account pages.
You return to the test app, your computer, or the wrong page.	Compare the destination used in this attempt with the public destination you intended.
You return to the right app, but it opens signed out.	Check whether the app completed sign-in and passed the result to the code that checks who you are.
You look signed in, then lose it after a reload.	Check whether the next page visit still carries the information needed to recognize the same account.

An empty account page needs one more distinction. Can the app identify the right person when it fetches that page's information? Supabase checks identity and permission to read data separately (opens in a new tab). If the person is recognized, ask AI to identify the missing record or access problem. Rebuilding login will not create a missing record.

If the email never arrives, the code is rejected, or resending fails, use the email-code guide for that part. Continue here when the code is accepted but the published app still fails to keep you signed in.

Have AI observe the attempt and inspect the matching error details. A generic message on the page may hide the useful cause. The result should identify the last working step and the first failed step, with enough detail to choose one repair.

Using the public address and test account from the previous check, follow one fresh attempt with the chosen sign-in method. Use the browser and authorized service tools available to you. Let me complete any personal Google login, consent, or email-code entry directly where required.

Record the last confirmed working step and the first failed step. Inspect the relevant error details for that attempt and compare with the working test version. Keep the time, page address without private values, and a plain explanation. Do not copy passwords, sign-in codes, private browser data, or other people's information into the report.

If Google sign-in takes me away from the app, distinguish Google's return to Supabase from Supabase's return to the app. For a typed email code, establish whether it was accepted before inspecting how the app keeps the person signed in.

If the page lacks account data, check which person the app recognizes while fetching it. Separate a failed sign-in from missing records or insufficient data access.

Do not change anything yet. Name the supported cause, the evidence for it, and the smallest repair to investigate. If the cause remains uncertain, perform the next relevant inspection and state what is still unknown.

After you run it: Look for a specific result, such as: sign-in was accepted, but the next app page could not recognize the account. A list of possible causes is unfinished diagnosis. If the evidence is missing, AI should name the next observation needed instead of choosing a fix at random.

Step 03Have AI fix that specific cause

The repair should explain the result you just observed. If the app returns to the wrong address, correct the setting or code that chose it. Supabase uses the app's requested destination when it matches the allowed list (opens in a new tab); its Site URL supplies the default when no destination is specified. Check those values before adding a new return page.

If sign-in disappears on reload, inspect how the app remembers it. In a setup where Supabase is used by both the browser and the server, they share sign-in information through small browser records called cookies. Supabase's guide to sharing sign-in information (opens in a new tab) explains that handoff. AI should follow the existing code and repair the point where the information stops reaching the next page.

Some settings only reach users when you publish a newly built version. Building means preparing the app's code to run. Next.js can copy browser-visible settings whose names start with NEXT_PUBLIC_ into that prepared code (opens in a new tab). Saving a different value afterward does not replace the value inside an existing build.

We checked this with a small local Next.js 16.3.5 app. We built it with a made-up test-service address, then started that same build with a different address. The page it sent back still contained the first value, while a separate server check found the new one. Rebuilding changed the address in the page too.

That test used example addresses and no real sign-in service. It shows why a saved setting can differ from what the app uses; it does not diagnose your login. If AI finds this mismatch in your app, the repair includes a fresh build with the intended settings and publishing that version to the public address.

Keep the fix small enough to explain. Changing a return address should not become permission to accept every destination. Restoring account information should not mean removing its access rules. If the problem turns out to be missing data, have AI describe that separate task before it changes how people sign in.

Repair the cause and update the public app

This prompt asks AI to carry out the repair, including service settings and publishing when those actions are allowed. It should explain any public change before making it. If your existing instructions require approval, you can review the exact change at that point.

Fix the specific cause supported by the previous inspection. Use my app's existing sign-in approach and the documentation for its installed versions.

Explain the setting or code change and why it addresses the observed failure. Preserve working sign-in methods, intended test addresses, and unrelated settings. Do not accept arbitrary return destinations, remove data protections, or expose a secret to browser code.

Perform the repair through available, authorized tools, including the connected service settings where needed. Read back changed settings and run the relevant code checks. Follow my existing approval requirements for public changes. If permission or access is missing, prepare the exact change for review, ask for the specific missing step, then continue when it is provided.

Check whether a changed setting needs a fresh build. If so, build with the intended values. Publish the repaired version within my authorized scope and confirm that my real public address opens it.

Report what changed, what you verified, and what still needs the full sign-in check. Do not describe a code check, saved setting, or successful build as a completed login test.

After you run it: AI should show how the change addresses the failed step and confirm whether it reached your public app. If it has only repaired a preview, finish publishing the reviewed fix before running the final check. Saving a setting is progress; seeing the public app use it is the next result.

Step 04Repeat the full sign-in check

Return to the same public address and repeat the attempt that failed. Start a new sign-in from the button. Reusing an old return-page link can add a different problem because the temporary code in it may already have been used (opens in a new tab). For Google, finish in the browser that started the attempt.

Check the account you reach, not just the page design. Then reload, open an account-only page directly, and sign out. After signing out, open that private page again. The app should ask you to sign in before showing its private contents.

Have AI collect these results while you perform any personal login steps. If the original problem happened on your phone, repeat there too. A desktop pass does not tell you what happened on a device nobody tested.

If sign-in stops again, return to Step 2 with that observation. The first repair may have exposed another problem further along. Keep the working part and investigate the new stopping point instead of starting the whole setup over.

The final prompt checks the reader's experience from start to finish. Ask for observed results beside each action, so an unfinished check cannot hide inside a general claim that everything works.

Verify the repaired app at the original public address. Confirm the version running there, then use one fresh sign-in attempt with the same method and test app account.

Check these actions in order:
1. Complete sign-in and reach the expected app page.
2. Confirm the app recognizes the intended account and shows its expected test information.
3. Reload and confirm the same account stays signed in.
4. Open an account-only page directly while signed in.
5. Sign out, then open that private page again and confirm sign-in is required before its private contents appear.

Use the available browser and service tools. Let me perform personal login, consent, code entry, or a physical-phone check when needed. If the original failure occurred on my phone, help me repeat those same steps there.

Record an observed result for each action, the public address, the app version, the method, and the browser or device tested. Mark any check you could not perform as untested. Keep account details and sign-in secrets out of the report.

If a step fails, identify the last success and first failure before proposing another change.

After you run it: The check is complete when the original failure is gone and every listed action has an observed result. Keep the short report with the fix. It tells you which version, method, account, and browser worked, without pretending that one attempt tested every other way to sign in.

Still having trouble?

Pull me into your project with @Vlad, your virtual co-founder. Or, if you'd rather work with the real me, set up a call.

Get @Vlad Setup a Call

Summary

When login works in testing but fails after publishing, start with the version your users actually open. Follow one attempt until you can name where it stops. Have AI fix the cause it can demonstrate, then repeat the full sign-in check at the same public address.

You should finish with a working sign-in and a plain explanation of what changed. That explanation matters the next time you publish. It gives you something specific to check instead of another round of guessing.

About the author

Vladislav Zhirnov

Co-Founder and CPO at Pinpoint

I'm Vladislav Zhirnov, Co-Founder and CPO at Pinpoint (opens in a new tab). There, I lead product strategy, contribute to early growth, and build AI systems that enable us to iterate quickly. Through this site, I help founders and product teams turn promising apps into successful products real people use.

Before this chapter, I spent more than five years at Side (opens in a new tab), growing from Product Manager Trainee to Director of Product Management. There, I led DUBS - a social gaming platform for teens - from concept to over 150,000 installs.

Away from the screens, I live on a homestead with Carl the mini-Highland cow and a rather large supporting cast.

To learn more about Pinpoint and the other projects I'm involved in, visit my portfolio.

Learn more about me

Sources

8 references

Choose your next move

Keep moving from idea to real use.

App Readiness CheckCheck the rest of your app before real people do.Use the App Readiness Check to find the next signup, data, payment, or publishing gap that could stop a real user.Check Your App Virtual Co-FounderBring @Vlad into the project.Bring @Vlad into the project to untangle a hard problem and turn the next move into a plan.Get @Vlad Hands-on helpWork directly with Vlad.Get direct help finding the actual problem and moving your app, AI system, or workflow toward real use.Setup a Call

Scan my page