Why your Lovable/Base44 signup flow breaks for real users, and how to catch it

You built the signup in Lovable or Base44. The screen looks like a real product. Your preview lets you in. You send the link to one person and they never arrive inside the app.

The usual reason is simple. You tested the path you already survived while prompting. They are testing the path a signed-out stranger gets. Those are different flows, even when they share a button. This guide names the breaks that show up again and again, then shows how to catch them with a browser session that signs up by itself, like a new customer, before a real person has to.

The same pattern applies if you stitched the app together in Claude Code or Cursor. The builder is different. The failure is the same: the happy path in the preview is not the first visit.

Two signups, one button

While you build, you are rarely a new user. The tool's preview may keep you signed in. You may have created the first account by hand in a dashboard. You may have clicked through an error once, remembered the workaround, and never looked at that screen again. The button still says "Create account." The behavior behind it depends on state you forgot you had.

A real first visit has none of that state. There is no session. There is no row in the user table for them. There may be a confirmation step you turned on and never finished. There may be two signup pages because one prompt added a modal and a later prompt added a full page, and the header points at the broken one.

Catching this means starting signed out, at the public URL, and finishing with proof that an account exists. "The button clicks" is not proof. Proof is a screen that shows the account, a row you can see in your own user list, or a clear check-your-email state that you then confirm with a real inbox.

If you remember only one habit, make it this: after any prompt that touches the header, the form, or the words "sign up," run signup once in a private window before you believe the preview.

Breaks that show up on these flows

These are the ones worth hunting. They are described in plain language because the fix is usually plain too.

The button that looks finished. The form submits, a toast says "Welcome," and the person is back on the marketing page, still signed out. The toast was hardcoded. The account was never created. Your preview hid this because you were already signed in, so the page bounced you to the app anyway.

The success message with no account. The screen says "Check your email" even when the email was blank or the request failed. The words were written by a prompt that assumed the request worked. The request was never connected, or it fails quietly.

The missing label. The placeholder says "Email" until the person types, then the field is a blank box. On a phone, they cannot remember which field is which. A screen reader cannot tell either. The report will call this an unlabeled field. It is a signup bug, not a nicety.

The error that lives in the console. The page sits there. Nothing changes. In the developer tools a red line says the request failed. Your user does not open developer tools. If a test records a console error on the signup page, read it. Then put a sentence on the page for the next person.

The email field that accepts anything. "Hello" submits, and the app either crashes or creates a junk account. Or the opposite: a normal address is rejected because the check is a confused pattern a prompt invented. Try one empty submit, one obviously bad value, and one normal address.

The second signup. The same email again should say the account exists or should sign the person in. A duplicate account, or a generic "something went wrong," is a bug you will meet the first time a real person retries.

The confirmation page that was never built. The email link, if you send one, opens a 404 or a blank route. You tested the form and not the link. Open the link in a private window. If you do not send email yet, the form should not tell people to check their inbox.

The social button that dead-ends. "Continue with Google" looks primary, and it is not wired. People click the thing that looks easiest. If it is not ready, remove it until it is. Test the email path as the path you actually support.

The sticky header that covers the button. On a tall phone-width window the create button sits under a bar, or under the keyboard area you did not leave room for. The desktop preview in the builder will not show this. A narrow window will.

The two routes. "/signup" works and "/register" is an old page that throws. The footer still links to the old one. A session that follows visible links will hit the broken one. Believe the link a stranger can see.

The password rules that appear too late. The form says nothing, then rejects the password after submit with a code name from the database. Say the rule next to the field, in words.

The redirect to a page that assumes data. Signup succeeds and sends the person to a dashboard that immediately errors because it expects a project they were never asked to create. The account exists and the app still looks broken. The first screen after signup is part of signup.

None of these require a clever test plan. They require a signed-out pass that you did not help.

How to catch them on purpose

Do one pass yourself, then do a pass you cannot quietly assist.

Your pass:

1. Private window. Public URL. Phone-width, then once at laptop width.
2. Find signup using only the words on the page.
3. Submit empty. Read the page, not the console, and write down what a stranger would understand.
4. Submit a bad email. Same note.
5. Submit a real address you control, with a password if the form asks. Follow it until you can prove the account exists.
6. If there is a confirmation email, open the link in the private window.
7. Sign out. Sign in with the same details.
8. Try the same email a second time and read the error.

Write three lines for every stick point. Those lines become the prompt you paste back into Lovable, Base44, Claude Code, or Cursor. The guide on fix prompts shows the shape that editors follow. A sentence like "signup is broken, please fix" will rewrite the wrong file.

Let a visitor sign up without you

Your own pass still has a leak: you built the form, so you know which field is the email even when the label vanishes. A drafted visitor does not.

Paste the public URL into Persqo. You do not verify the domain. Persqo drafts three visitors from the page. Because a signup page has a start or sign-up action, one goal will usually be to sign up. Edit that goal so the finish line is visible: "Sign up and reach a screen that shows the new account," or "Sign up and reach the screen that says to check email," if that is as far as your app truly goes. Edit the other two goals so they are different jobs, such as finding the price and following the main button. The persona guide walks through that edit. Accept once.

Each visitor gets a real browser. The signup visitor looks for an email field. If it finds one, and the goal is to sign up or start, it fills a test email, fills a test password when a password field is there, fills a name field when that is obvious, and clicks a button whose words look like sign up, start, create, continue, join, or try. Then it reads the page it landed on.

That is a real submit on your app. Plan for a test user named with visitor@example.com. Delete it later if you want a clean table. The point is that the form ran.

What the visitor will not do: pay, send a text, message a real person, delete an account, change an existing password, or publish something in public. If your only "signup" is a checkout, the visitor stops before payment. You will see that the path dead-ends at a card form. You will not get a fake receipt.

The report tells you whether the goal was reached or the visitor got stuck, and on which page. Screenshots show the form and the page after submit. The session replay lets you watch the typing and the click. When the run records video, the replay is a video. You also get a fix prompt aimed at Claude Code or Cursor, which you can paste into Lovable or Base44 the same way. The prompt says to patch the site so this visitor can finish the goal, to keep the current design, and not to add a way around payment.

A few findings are especially common on signup, and the session will name them when it sees them: the page returned an error, a script threw in the console, a field had no label, the layout overflowed the screen, a link in the form area went to a dead page, or the goal was not visible after submit. None of those are guesses. They are tied to a screenshot and a step.

How to read a stuck signup

Read the signup visitor first, even if another visitor found a missing image alt. Alt text matters and it is not why people cannot join.

Open the replay and answer these questions before you change code. The replay guide is the longer version of watching. For signup, the questions are short.

• Which button did the visitor click? If it clicked a secondary button, your primary one may be unclear, or the primary one may not look like signup.
• Did the URL change after the click? No change, plus no message, usually means the submit did nothing.
• What text appeared? If the only change is a toast and the URL is the home page, you likely have a success message without a session.
• Is the email visible in the screenshot of the filled form? If the field is the wrong field, the labels failed.
• Did the run record a console error on that page? If yes, that error is part of the prompt you paste. Do not leave it as a private clue.

Then look in your own user list. If visitor@example.com is missing, the account was not created, no matter what the toast said. If the account is there and the visitor is still on the marketing page, the bug is the step after create: the redirect, the session cookie, or the first screen. Say which of those you want in the prompt. "Fix signup" is too wide. "After a successful create, send the new account to a page that shows their email, and do not bounce them to the signed-out home" is a job an editor can do.

Paste that, plus the fix prompt from the report, into the builder where the app lives. If the builder offers a preview, ignore the preview until you run the same goal again from a signed-out session. Previews are how this bug survived the first time.

A worked catch

Made-up, so you can see the sequence. A membership site built in Base44. The preview opens on the member home because the builder stored a session. The public home has "Join."

You paste the URL. You edit the first goal to "Sign up and reach a screen that shows the new account." You accept.

The phone visitor fills the email and a password and clicks Join. The replay shows a toast, "You're in," and then the marketing page. The screenshot of the next step has no email in a header. Your user list does not contain the test address. The report says the visitor got stuck on the home page. A console note says the create request returned an error. The page never showed that error.

You copy the fix prompt and add one sentence: show the error on the form, and on success go to a page that displays the account email. You paste it into Base44. You do not ask it to redesign the hero.

The second run creates the test account and lands on a page with the email. You delete the test row if you do not want it, or you leave it as the canary and reuse that goal after the next prompt. You still check the confirmation email yourself if you turn that on later. You still click Continue with Google yourself, and you remove it until it works.

The laptop visitor, in the same run, finds a footer link to an old register page that returns an error. That is the "two routes" break. It goes in a second prompt, or in the same prompt if you are disciplined about naming both URLs. The third visitor looks for a price. You learn the price is only mentioned after login, which you already intended. You leave it.

What to put in the builder prompt

Keep the prompt narrower than your frustration.

• Name the page and the button text.
• Say what the test visitor did, in order.
• Say what the screen showed, and what your user list showed.
• Say the screen you want after success.
• Say to keep the current visual design.
• Say not to remove the form, not to skip auth, and not to pretend a payment succeeded.
• Say to put any failure on the page in a sentence a person can read.

Run the visitor again. Tick signup only when the goal is reached and, when you care about the inbox, when you have opened the real email once.

Signup is the door. Lovable and Base44 are good at painting the door. A signed-out session is how you learn whether it opens. Do that before a real user is the one who finds out it does not.

Questions people ask