Inside the repair shop / How it works
A repair you
can follow.
From a stubborn bug to a fix you can check.
Unslop repairs login, payment, and paid-access problems in Lovable apps. We trace the cause, explain the work, and test the customer journey the bug interrupted.
Follow a repairThe repair process
Five stops.
One focused repair.
A login loop can have several causes. We reproduce the failure in your app and agree on the behavior the repair needs to restore.
Read about project access-
Describe
Show where it gets stuck.
Send the app link, what you expected, and what happened instead. A short recording or a screenshot can help. You don’t need to know which piece of code is responsible.
Start with the symptom. Leave passwords and secret keys out.
-
Agree
Put the repair in writing.
Agree on the scope, fixed quote, success criteria, access, and timing before repair work begins. Any access needed to assess the problem should be explained and agreed separately.
A useful success criterion: “A signed-in customer stays signed in after reloading.”
-
Investigate & repair
Find the cause. Fix the fault.
We reproduce the failure, trace it to its cause, and prepare a focused change in a separate working copy or test environment. We check the agreed behavior and the related steps that could be affected.
A payment repair also needs checks for retries. An access repair needs an unpaid-account check.
-
Review & approve
Try it. Then give the go-ahead.
Review the changes and check results, then try the steps yourself. You approve the deployment plan before any changes reach your live app.
Submitting an inquiry is not permission to change your app.
-
Hand back
Keep the repair record.
The handoff includes the changes, instructions to check the result, and known limits. It also identifies temporary invitations or credentials to revoke, with any further work agreed separately.
See a sample handoff
Keys to the workshop
Access should have
a reason to exist.
A screenshot may explain the symptom. Finding the cause may need a closer look.
Explain the request.
A repair may need code, project settings, or relevant logs. We explain which permissions we need and what each lets us investigate.
Limit what’s shared.
Prefer a project invitation with limited permissions, test accounts, and redacted logs where they are sufficient. Don’t put passwords, API keys, payment details, or customer records in the request form.
Close out the access.
Revoke temporary project invitations when the agreed work is complete. Your handoff identifies the access to remove and any shared credentials to replace.
Something you can inspect
The repair comes
with the receipts.
Your repair record explains what changed, what passed, and which parts of the app were outside the checks.
Example handoff. A fictional login repair showing the record you can review.
- Reported
- Signing in returns the customer to the login screen.
- Example change
- Wait for the saved session to load before deciding whether to show the login screen.
| Check | Illustrative result |
|---|---|
| Sign in with a test account | App opens |
| Reload the app | Still signed in |
| Sign out, then revisit | Login required |
Not checked: password resets, other sign-in methods, or production traffic.
Change summary · Reviewable changes · Repeatable check steps · Access closeout list
Start with what you can see
“It does this.
It should do that.”
That’s enough to start describing the problem.
Describe your repair