7 Old Links and Logins to Check After Launching Your AI-Built App
Launching on a custom domain does not automatically answer what happened to every earlier link
If you recently launched your app, you might wonder whether your Lovable preview URL is still public after launch. Before launch, you probably shared links with testers, collaborators or early customers. Lovable, Bolt and Replit made that easy. After launch, some of those addresses may still work.
That is not automatically a problem. An old link might show only a harmless page. But it is worth knowing exactly what each link and login allows before you send more people to your live app.
Work through this checklist using a private browser window while signed out. For every address, record three separate answers:
- Can someone open the page?
- Can they find it through search?
- Can they view data, change data or manage the project?
These are different questions. A page that opens may not expose customer data. A page missing from search results may still be available to anyone with its address. Check only apps and accounts you control, and avoid changing customer records while testing.
1. Check if your Lovable preview URL is still public
Why it matters: A preview is a version of your app you can view or share before, or alongside, the live version. If your Lovable preview URL is still public, someone who received an earlier link can still open a screen you no longer want to share.
How to check: Search old emails, messages and bookmarks for Lovable links. Open each one while signed out, then compare it with your live custom domain. Does it show the current app, an older screen or a page that should require a login? Write down exactly what is visible.
What to do next: Decide whether each link still has a purpose. Review Lovable's publishing and access documentation before changing settings. If a page should be private, confirm that the right login is required. Do not rely on the fact that the address was not widely shared.
2. Check the original Bolt publish link after launch
Why it matters: You may have shared a generated bolt.host address before you began promoting your custom domain. An active Bolt publish link after launch can leave early prototypes reachable by testers or customers who bookmarked the original address.
How to check: Find the first Bolt publish link in your launch notes, messages or browser history. Open it while signed out. Then open your custom domain in a separate private window. Compare the page, login requirement and visible business information. Does the Bolt address show the current version, an earlier version or an error?
What to do next: If the link shows an old or unintended version, check Bolt's current publishing instructions. Confirm which controls apply to your project, make one change at a time, then repeat the signed-out test. Do not assume that connecting a custom domain removed the earlier address.
3. Check whether your Replit deployment is still accessible after custom domain setup
Why it matters: A deployment is a running version of your app available at a web address. An earlier Replit deployment still accessible after custom domain configuration can expose obsolete business logic or unmonitored test endpoints.
How to check: Search launch notes, test messages and bookmarks for Replit deployment links. Open each while signed out. Note which version appears and whether it asks for login where you expect one. If two versions look similar, compare a harmless detail, such as the page title or a feature you know changed. Do not enter or edit customer information to identify the version.
What to do next: Decide whether each deployment is still needed for testing or support. If it is not, review the current deployment settings or ask someone familiar with the project to help you change them safely. Then test the address again. Replit projects can be configured in different ways, so check your specific setup.
4. Review guest shares and project invitations
Why it matters: Sharing your running app is different from inviting someone into the project where it is built. A former tester may no longer need either type of access. A project invitation can allow far more than viewing a page.
How to check: List everyone who received a test link, public share or project invitation. For app links, test what a signed-out visitor can see. For invitations, review the people and permissions listed in the project settings you control. A signed-out browser cannot show what an invited collaborator can do after they log in, so check that separately.
Lovable's project sharing documentation explains its sharing routes. Read the current permissions before removing or changing access.
What to do next: Remove invitations that are no longer needed, or adjust the relevant share settings. Then verify the result. The important question is not whether a link exists. It is whether that person can view the app, enter the editor or manage the project today.
5. Test your admin area while signed out
Why it matters: An admin page can be absent from the menu but still have a reachable address. Being hard to find is not the same as being protected. Unprotected routes often point to deeper application security issues in AI code where permissions were skipped during rapid generation. What matters is whether the right person must log in before viewing data or taking action.
How to check: If your app has an admin area, open its known address in a private browser window while signed out. /admin is common, but use the address your app actually uses. Does it show a login screen, a blank page, business information or controls?
Seeing a page frame does not necessarily mean someone can access data. If you have a separate non-admin account that you are authorised to use, sign in with it and check whether it can reach the admin area. Do not change records or submit forms.
What to do next: If the wrong account can view sensitive information or reach controls it should not have, pause sensitive work in that area and have the login and permission rules reviewed. Removing a menu item or keeping a page out of search results will not fix an access rule.
6. Review test users who can still sign in
Why it matters: During building and testing, you may have created sample, test or admin accounts. Some may still work in the live app. This is a check of your own access list, not an assumption about the AI tools you used.
How to check: Review the accounts visible in your live app's user or admin settings. For each likely test account, record:
- Who owns it
- Why it exists
- What level of access it has
- Whether it is still needed
If you know the credentials and are authorised to use them, test sign-in in a private window. Check what the account can view, but do not edit customer data. If you cannot safely test an account, record that uncertainty.
What to do next: Disable accounts that are no longer needed through your normal account controls. Replace shared test credentials with accounts owned by named people. If disabling an account could interrupt a live process, get it checked before making the change. Following a structured set of engineering standards for AI apps helps you manage these user states reliably.
7. Check staging directly, then check search separately
Why it matters: Staging is a separate version of your app used to test changes before they reach the live version. A staging page may be open to visitors, appear in search results, both or neither. Treat each possibility as a separate check.
How to check: Search for the old staging hostname, then open any results while signed out. Next, open the staging address directly, even if search finds nothing. Record whether the page loads, what it shows and whether it asks for login before displaying anything sensitive.
A search result does not prove that a page is currently open. A direct visit tells you more about current access. Likewise, an address missing from search can still be available to anyone who has it.
If you use Vercel, its preview indexing guidance explains its own preview indexing behaviour and notes that a custom domain on a staging branch changes the situation. Check your setup before applying that guidance. Keeping a page out of search does not stop someone with the address from opening it.
What to do next: Decide whether outside testers still need staging access. If they do not, review access settings with someone who understands the deployment before changing them. If staging must remain available, confirm that its login and permissions match the information it contains.
Keep a simple record
Use one row for each check. Add extra addresses or accounts under a row as needed.
Check | Address or account | What a signed-out visitor can do | Still needed? | Next action |
|---|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
For invitations and user accounts, add a separate note about what a signed-in person can do. This keeps page access, search visibility and editing permissions from becoming one vague concern.
A link and login review is only one part of keeping an AI-built app dependable. A code quality audit looks at a different question: whether the code behind the app is safe to keep building on.
You can keep building the app you already have without starting over. If you want a senior engineer to review these access paths and your AI-generated code with you, Smicolon's Solo Founder Plan offers €1,000 per month for 40 hours (€25 per hour) with a 3-month minimum. It includes a weekly 1-hour 1:1 with a senior engineer and a thorough check on what the AI wrote, so you stay the builder. Hour plans end at the end date or when the hours are used up, whichever comes first. Bring the record from this checklist to a discovery call, and you will have a concrete starting point for the conversation.