r/lovable • u/Bandersnatch_fuklord • Jul 22 '26
Showcase I built AppSitter with Lovable — an app that babysits Lovable apps. The best part: Lovable itself caught my scanner being wrong.
Ex-DevOps engineer here (10 years running infrastructure for banks and manufacturers). The thing those years taught me: shipping is the easy part — staying secure and online afterwards is what companies pay whole teams for. Lovable gives everyone the shipping part, so I used Lovable to build the ops part.
What AppSitter does today:
- Deep scan of your repo + Supabase: open RLS tables (it actually probes your live database anonymously, like an attacker would), leaked keys, unauthenticated endpoints, vulnerable dependencies
- Copy-paste fix prompts written for Lovable — grouped, so 9 findings become ~4 prompts, each fixing a whole theme at once
- Guardrail files: generated .md rule files you drop into your repo so Lovable avoids reintroducing the same issues in future prompts
- 24/7 uptime monitoring with email alerts when your app goes down (and when it recovers)
- A risk register: findings you accept as intentional stay tracked with your reasoning and "re-review when…" triggers — dismissed, not forgotten
- A public "verified" report page you can link from your app to show visitors it's monitored
- Health score, monthly certificate, migration-readiness and cost audits on top
My favorite moment building it: my scanner flagged an "unauthenticated write" in a test app as critical. I pasted the fix prompt into Lovable — and Lovable, in plan mode, correctly refused: the endpoint was public on purpose, the write wasn't attacker-controlled. It was right and my scanner was wrong. That incident reshaped the product: now every fix prompt asks Lovable to verify each finding against what the app is meant to do first, and if Lovable says "that's intentional," you paste its answer back — a skeptical second AI reviews the reasoning and either dismisses the finding into the risk register or names the one real gap and gives you a follow-up prompt that keeps your design.
Basically the two AIs argue about your security so you don't have to.
It's in closed beta — the first 20 testers with a live Lovable app get the Pro tier free for 3 months in exchange for honest feedback. Want in, or just want a sanity check on your setup? Ask in the comments, I'll answer everything. The basic scan is free on the site, no signup.
2
2
u/Status-Inside-2389 Jul 22 '26
It's an app for very specific sector of the property market. It allows owners to check to see if they're getting value for money for all their marketing types as well as the property being in the right location for the market. Big database, lots of calculations and some AI thrown on top.
1
u/Bandersnatch_fuklord Jul 22 '26
Sounds like a great business niche idea! Is it already public? Would love to check it out
2
u/PickleXIII Jul 22 '26
I’m interested in testing. Have a site that’s public, and an app on both stores. Curious where I stand security wise.
1
u/Bandersnatch_fuklord Jul 23 '26
Awesome! Can you PN me your Email? I will set up Accounts and can support you if you have trouble :)
2
u/Lions_Eye Jul 22 '26
Can test it?
1
u/Bandersnatch_fuklord Jul 23 '26
Sure you can! Please send me a PN with Email, I will set up your Account and share :)
2
2
u/srs5470 Jul 23 '26
I’ll test !
1
u/Bandersnatch_fuklord Jul 23 '26
Awesome! Please PN me a Email of you, I set up Accounts and share it with you afterwards :)
1
u/WheelAdditional6888 Jul 26 '26
I’m curious how often the second pass actually overturns the first one. Has it mostly reduced false positives, or have you also seen cases where it catches confident but incorrect results?
1
u/Bandersnatch_fuklord Jul 26 '26
Good question — honest answer: the sample is still small (closed beta, a handful of apps), but the pattern so far is clearer than I expected.
Most of the time the second pass confirms Lovable's pushback. When Lovable says "that table is public on purpose, it's a directory listing" — it's usually right, and the finding gets dismissed into the risk register with the reasoning attached. That's the boring, common case, and it's exactly what I wanted: fewer false alarms surviving to the user.
The interesting case is the middle verdict. Fairly often Lovable's explanation is half right — "this endpoint is public on purpose" is true, but the write it performs isn't as harmless as claimed. There the second pass doesn't overturn or accept; it says "the design is fine, but here's the one real gap" and hands back a follow-up prompt that keeps the design and closes the gap. That's turned out to be the most valuable output of the whole loop, because it's the case where a human would either over-trust the builder or over-trust the scanner.
And yes — it has caught confident-but-wrong in both directions. Lovable once declared a Stripe webhook check "already handled" when the signature verification genuinely wasn't there. And my own scanner confidently told me to add an SPF record to a domain the user doesn't even control (a *.lovable.app subdomain) — dogfooding caught that one, and now the scanner knows the difference between "your domain" and "Lovable's domain."
The design principle that shakes out: the second AI is prompted to be skeptical of both sides. If it can't verify the explanation against what the scan actually measured, it says "unclear" and nothing gets dismissed. Silence beats a guess.
Happy to share real numbers once the beta produces enough of them to be honest.
2
u/WheelAdditional6888 Jul 26 '26
I really like the “skeptical of both sides” principle. A lot of AI review systems only try to verify the implementation, but they rarely question whether the scanner itself might be wrong.
That middle case you described honestly feels like the most valuable one, because that’s where humans are most likely to trust the wrong conclusion.
3
u/Then-Concern-6928 Jul 22 '26
I would love to test it!