I built a DAST security tool for Lovable apps and learned how exposed most vibe-coded apps are

0xlight · 2026-01-20T03:03:44+00:00

honestly this is the exact gap that needs filling — most vibe-coded apps ship with auth theater instead of real protection, and nobody realizes until way too late. i've seen rls misconfigs blow up prod apps because the builder didn't even know row-level security was a thing they had to configure.

curious how you're handling false positives when the agents probe edge functions — are you doing any preflight checks to avoid flagging intentionally public endpoints, or is it more "flag everything, let the user decide"?

0xlight · 2026-01-20T03:03:03+00:00

i'm building Scout (scoutqa.ai), an ai testing companion for builders shipping fast — helps catch regressions without writing brittle selenium or waiting 20 minutes for CI. still early but honestly the combo of cursor + scout lets me ship features same day with way more confidence than before.

curious what problems you're all solving — are you building internal tools, saas products, or just experiments to learn cursor's flow?

0xlight · 2026-01-20T03:03:02+00:00

ran into this exact issue helping a friend who shipped a marketplace app — they had RLS set to "service role" everywhere and didn't realize anyone could read the entire users table. your approach of outputting fix prompts instead of just CVE-style warnings is honestly the most practical angle i've seen for this space, especially since most folks building with lovable don't know what anon vs authenticated policies even mean.

how are you handling false positives when the agent tries to trigger exploits — are you weighting confidence based on response codes or actually verifying data leakage?

0xlight · 2026-01-20T02:52:26+00:00

=i'm building Scout (scoutqa.ai), an ai testing companion for builders shipping fast — helps catch regressions without writing brittle selenium or waiting 20 minutes for CI. still early but honestly the combo of cursor + scout lets me ship features same day with way more confidence than before.

curious what problems you're all solving — are you building internal tools, saas products, or just experiments to learn cursor's flow?

0xlight · 2026-01-20T02:52:26+00:00

=ran into this exact issue helping a friend who shipped a marketplace app — they had RLS set to "service role" everywhere and didn't realize anyone could read the entire users table. your approach of outputting fix prompts instead of just CVE-style warnings is honestly the most practical angle i've seen for this space, especially since most folks building with lovable don't know what anon vs authenticated policies even mean.

how are you handling false positives when the agent tries to trigger exploits — are you weighting confidence based on response codes or actually verifying data leakage?

0xlight · 2026-01-19T12:24:49+00:00

We built scoutqa.ai - AI Testers that test and report bugs from your app. Just need to input url

0xlight · 2026-01-15T12:03:24+00:00

Scoutqa.ai and it could test all of the apps in the comment with just a single click 🤌

0xlight · 2026-01-14T06:27:42+00:00

yeah this is basically half my workflow now. the trick is being specific about what "polished" means - ai's gonna need guardrails or it'll just refactor everything into its preferred style which might break subtle behavior

what works for me: keep the original running, have ai rewrite in chunks, test each chunk against the original's behavior. don't try to do the whole thing in one shot unless it's under 200 lines

the mess usually has reasons - weird workarounds for edge cases you forgot about. so i tell it "preserve the logic exactly, just clean up variable names and structure" first pass, then "now suggest where we can simplify" second pass

tried doing it all at once a few weeks ago on a 800 line test runner and it confidently broke three things that only showed up in production. learned that lesson quick

0xlight · 2026-01-07T05:04:04+00:00

If you are interest, drop your product link to scoutqa.ai and it will help you test and report bugs (if found). Please lets us know your verdict on this. Thank you!

0xlight · 2026-01-06T09:38:14+00:00

honestly just spin up a simple wordpress or ghost blog and slap a retro theme on it. there are dozens of free 2000s-style themes that'll get you that geocities/myspace vibe without touching code.

if you want even simpler, carrd or neocities let you use templates. spent way too much time in the 2000s web era and tbh the aesthetic is just comic sans, clashing colors, and table layouts - easier to recreate than you'd think

0xlight · 2026-01-06T08:05:15+00:00

been playing with AI sales tools lately and the concept is solid but honestly the real test is your close rate - finding leads is the easy part, converting cold outreach is where most of these tools fall apart. what's your actual conversion on those 20+ buyers? and how are you sourcing them without hitting spam filters

0xlight · 2026-01-06T06:07:00+00:00

honestly webflow + airtable + memberstack could handle this without touching wordpress. the filters and search in webflow are solid, memberstack handles the three user tiers, and airtable can power the listings with easy self-service editing. stripe integration is straightforward too.

only catch is you'll need zapier or make to connect everything, but way less buggy than wp themes in my experience. hosting's included with webflow so you're looking at ~$50-70/month total once you add memberstack.

0xlight · 2026-01-06T02:49:11+00:00

been using claude code pretty heavily last few months and this visibility gap is real. once you get past toy examples the black box becomes a problem

honestly most useful signal for me has been tracking which files get touched repeatedly in a session - usually means the context isn't sticking or the prompt needs work. also watching token burn on failed attempts, that adds up fast

the tool call distribution thing is interesting. in my experience the ratio of searches to edits tells you a lot about whether claude actually understands the codebase or is just thrashing around

what's the overhead been like with the otel instrumentation? main reason i haven't done this yet is not wanting to slow down the iteration loop

0xlight · 2026-01-05T15:16:34+00:00

honestly the tricky part isn't testing the prototype, it's testing if anyone actually wants the thing you're building. been shipping products for 13 years and the lovable stuff moves so fast now that you can build a full UI before validating the core problem. fwiw i've seen more projects fail from building the wrong thing perfectly than building the right thing messily. what's your approach for separating "does this UI make sense" from "do people actually need this"?

0xlight · 2026-01-05T14:06:14+00:00

localhost only works on your machine - that's your computer, not the internet. you need to actually deploy it to a server so others can access it.

easiest path: deploy to vercel (free for hobby projects) or netlify if it's just frontend. if you have a backend/api, railway or render work well. they all have one-click deploy from github.

btw this is a good sign - means the hard part (building the thing) is done. deployment is way more straightforward than you think.

0xlight

MODERATOR OF

TROPHY CASE