Sign-up worked when I tested it, but new customers can't sign up on my live site. Why?

AI app builders give you two copies of your app: the preview, which you see while you build, and the published site, which customers use at your real web address. They don't always match:

• Lovable explains that changes you make after publishing don't go live until you publish again (Lovable Docs).
• Apps keep some settings outside the code (developers call them environment variables). In apps built with the Vite tool, which many AI builders use, these are fixed in place when the app is built (Vite docs), so a change needs a new publish.

Signup also depends on the service that handles accounts, often Supabase, Firebase or Clerk. Five settings in these services cause most of the trouble.

Supabase has a setting called the Site URL: your app's web address, used in the links in signup and password-reset emails. During building it's often localhost, which means "this computer" and only works on the developer's own machine.

Supabase's docs say to change it to your real address, because email confirmations and password resets depend on it (Supabase Docs). If it's wrong, a new customer clicks the link in their email and gets a page that doesn't load.

In a public report from May 2026, a developer said that after changing this setting, the email links still pointed to localhost (Supabase on GitHub). So check a real email, not only the setting.

After someone signs in, they're sent back to a page in your app. That page's address is the redirect URL, and Supabase only sends people to addresses on an approved list.

A contributor to Supabase's code explained in a public thread (October 2024) that the address must match exactly: your domain on its own, or an http:// version, doesn't count (Supabase on GitHub).

So adding a new web address, or a "www." version, can break signup without anyone touching the code.

Firebase, Google's sign-in service, only allows sign-in from web addresses on its list of authorized domains (approved addresses). Its help page says a missing address is the most likely cause of the "not authorized" error people then see (Firebase Docs).

An API key is a long code that works like a password between your app and another service. Clerk, another sign-in service, gives you separate keys for testing and for the live site, and its guide says forgetting to switch to the live keys is a common mistake (Clerk Docs).

Supabase's built-in email sender is for testing, and its docs say it isn't meant for real use. Unless you connect your own email service (Supabase calls this custom SMTP), it only sends to people on your project's team, and only "2 messages per hour" (Supabase Docs). Supabase says that limit can change.

So the email reaches you when you test, and never reaches your customers.

People who can't sign up don't become customers. People who can't log in can't use what they paid for. Few write to tell you.

An example with made-up numbers (put in your own): 300 people a week open your signup page, 1 in 10 signs up, and 1 in 6 of those later pays $20 a month. That's 5 new paying customers a week. If the email links are broken for 2 weeks, about 10 paying customers never get started: $200 a month missing, for every month they would have stayed.

The settings take minutes to fix. The cost comes from not knowing.

After each publish, and after any change to your web address:

1. Sign up on your live site in a private browser window, using an email address that isn't on your team.
2. Open the confirmation email and hover over the link. It should start with your real web address, not "localhost".
3. Log in and out on the live site, including with "Sign in with Google" if you offer it.
4. Ask for a password reset and follow the link to the end.
5. In Supabase, open Authentication, then URL Configuration. Check that the Site URL is your real address and that it's in the Redirect URLs list (with and without "www." if you use both).
6. In Firebase, go to Security, then Authentication, then Settings, and check your domain is under Authorized domains (Firebase Docs).
7. Ask your developer: "Is the live site using the live keys? Did you publish again after changing settings? Do our emails go through our own email service?"

Heedza opens your live landing, signup, login and checkout pages in a real browser on a schedule: daily on the free plan, or every 60, 30 or 15 minutes on paid plans. It checks that the signup page shows its email box and the login page shows its form, and it also checks the password-reset page. Every plan checks that your homepage is up (every 5 minutes on Free, every minute on Solo and Starter, every 30 seconds on Pro and Business), and when a new version of your homepage goes live, a full page check runs soon after.

If a page breaks, Heedza sends you a screenshot and a fix prompt, a ready-written request you paste into the AI tool you built with.

What it can't see: Heedza never signs in, fills in a form or pays. So it can't tell you that a confirmation email has a broken link or never arrived. Those need the checks above.