u/famelebg29

This sub ships apps faster than any community I know, and then the launch thread gets forty visitors and everyone concludes the product is bad. The product is usually fine. What is missing is a repeatable loop, so here is mine. Fifteen minutes a day, no face on camera, no budget.

Minute 1 to 10: make one TikTok slideshow. Five static images, text written on top of real screenshots of your product. Not video. Slideshows take minutes instead of hours, the swipe is an engagement signal the algorithm rewards, and they read like a friend's photo dump instead of an ad so nobody scrolls past on principle. Canva plus your phone is enough.

The only part that matters is the first slide. Write it lowercase, under ten words, and make it a pain your user would say out loud. "i ran a free security scan on my site and the results scared me" outperformed every clever line I ever wrote. Your product name does not belong on slide one, the last slide is the only place you are allowed to sell.

Minute 10 to 15: reply to every comment from yesterday's post within the hour you are online. Replies are the most underrated ranking signal and they cost nothing.

Once a week: look at which two hooks performed best, kill everything else, make three variants of the winners. That is the entire optimization system.

Expectations, because this is where everyone quits: the first three weeks feel like posting into a void. My first month was a few hundred views total. The curve is flat and then it jumps with no warning, and if you judge the channel at week three you will wrongly conclude it does not work.

Full transparency: I got so sick of doing this loop by hand that I turned the automation into my actual product, it is called Cinerads. Not dropping a link here, it is on my profile if you are curious. The manual loop above costs zero and works fine without any tool.

What has actually brought users to your vibe coded projects? Genuinely collecting data points, the answers in threads like this are usually better than any guide.

i'm building bullynx, an AI copilot that analyzes trading charts. honest update from the trenches.

the lesson that cost me a month: i built what i thought was impressive instead of what users asked for. spent weeks polishing features almost nobody touched. meanwhile the most requested change was embarrassingly simple: traders wanted the invalidation level shown FIRST, before the reasoning. traders scan, they don't read. one afternoon of work, immediate difference in how people used the product.

what's actually working: the free calculators (position size, risk/reward) bring in more of the right people than anything i've tried to pay for. and replying to every single piece of feedback within hours. in a market where everyone's been scammed by signal sellers, "the founder actually answered me" is a feature.

what's hard: the constant suspicion. every trading tool gets assumed to be a scam until proven otherwise, and honestly, the skepticism is earned by this industry. you don't fight it, you just outlast it by being consistently boring and honest.

if you trade, the free tier is at bullynx.com. tear the chart reads apart, that's the feedback i need.

question for the room: what's the feature you spent weeks on that nobody used? need to feel less alone on that one.

i've spent the last months building bullynx, an AI copilot that reads chart screenshots and gives a long/short bias with invalidation levels. educational only, no signals.

here's what surprised me about building in this space.

the compliance constraint shaped the product more than the AI did. the line between "educational analysis" and "investment advice" isn't a disclaimer you slap on at the end, it's a design decision in every single output. we force every read into the same format: bias, reasoning, invalidation level. never "buy this." the structure itself is the compliance.

second surprise: traders don't distrust AI, they distrust YOU. this market has been burned by signal sellers, pump groups and discord gurus for a decade. my biggest conversion lever isn't a feature, it's the sentence "we don't sell signals." that's it. that's the moat.

third: hallucination is an existential risk here, not a UX annoyance. a generic LLM will confidently invent support levels that don't exist on the chart. grounding every claim in what's actually visible in the image was most of the engineering work.

for those building in fintech: what did you find harder, the regulatory line-drawing or earning user trust? and for anyone who's dealt with AI hallucination in a financial context, how did you approach grounding?

I run a security scanner specifically built for vibe coded apps (lovable, cursor, claude code, base44, etc). this week I scanned 50 lovable apps that were posted to this sub or shared in the lovable discord. 41 of them had at least one finding I'd consider "fix this before tweeting your launch".

the breakdown:

22 had RLS misconfigurations on supabase. anyone authenticated could read other users' data with a simple ID change in the request URL. classic IDOR.

17 had hardcoded API keys in the client bundle. mostly OpenAI and Stripe. one had a Supabase service role key (the master key) directly in the JS that runs in every visitor's browser.

14 had no rate limit on /auth or /signup endpoints. spammers can create thousands of fake accounts in minutes, which destroys email deliverability the second they start sending.

11 had no DMARC or weak DMARC. founders sending support emails from "support@theirapp.com" had no protection against someone else sending phishing emails impersonating their domain.

8 had cookies without HttpOnly or Secure flags. session hijacking via XSS becomes trivial.

what's painful is that lovable defaults handle some of this fine if you don't touch it. but the moment you ask lovable to "add user accounts" or "store user files" or "let users upload images", it generates code that breaks the defaults. the AI optimizes for "it works", not "it's safe".

three things you can verify on YOUR app right now without any tool:

1. open your supabase dashboard, go to your tables, click "auth policies". if you see any table with "no policies" listed, that table is wide open. add policies that scope reads/writes to the authenticated user's own row.
2. open your deployed app in chrome, hit f12, go to the network tab, refresh. look at the JS bundles being downloaded. ctrl+F for "sk_live", "sk_test", "AKIA", or your supabase project URL. if you see your service_role key, panic and rotate it. anon key is fine, service_role is not.
3. in terminal: curl -X POST https://yourapp.com/api/auth/signup -H "Content-Type: application/json" -d '{"email":"test@test.com","password":"x"}' 100 times in a row. if all 100 succeed, you have no rate limiting. attackers will find this in 10 min.

if you want the full automated check, I built zeriflow.com (free quick scan, no signup needed for the basics, 60 sec). but the manual checks above will catch 80% of what kills lovable apps post-launch.

would love to know if anyone here has shipped without checking these. genuine question, not a gotcha. if half of you say "yeah I never checked", that's the gap I'm trying to close with the tool.

I run a security scanner specifically built for vibe coded apps (lovable, cursor, claude code, base44, etc). this week I scanned 50 lovable apps that were posted to this sub or shared in the lovable discord. 41 of them had at least one finding I'd consider "fix this before tweeting your launch".

the breakdown:

22 had RLS misconfigurations on supabase. anyone authenticated could read other users' data with a simple ID change in the request URL. classic IDOR.

17 had hardcoded API keys in the client bundle. mostly OpenAI and Stripe. one had a Supabase service role key (the master key) directly in the JS that runs in every visitor's browser.

14 had no rate limit on /auth or /signup endpoints. spammers can create thousands of fake accounts in minutes, which destroys email deliverability the second they start sending.

11 had no DMARC or weak DMARC. founders sending support emails from "support@theirapp.com" had no protection against someone else sending phishing emails impersonating their domain.

8 had cookies without HttpOnly or Secure flags. session hijacking via XSS becomes trivial.

what's painful is that lovable defaults handle some of this fine if you don't touch it. but the moment you ask lovable to "add user accounts" or "store user files" or "let users upload images", it generates code that breaks the defaults. the AI optimizes for "it works", not "it's safe".

three things you can verify on YOUR app right now without any tool:

1. open your supabase dashboard, go to your tables, click "auth policies". if you see any table with "no policies" listed, that table is wide open. add policies that scope reads/writes to the authenticated user's own row.
2. open your deployed app in chrome, hit f12, go to the network tab, refresh. look at the JS bundles being downloaded. ctrl+F for "sk_live", "sk_test", "AKIA", or your supabase project URL. if you see your service_role key, panic and rotate it. anon key is fine, service_role is not.
3. in terminal: curl -X POST https://yourapp.com/api/auth/signup -H "Content-Type: application/json" -d '{"email":"test@test.com","password":"x"}' 100 times in a row. if all 100 succeed, you have no rate limiting. attackers will find this in 10 min.

if you want the full automated check, I built zeriflow.com (free quick scan, no signup needed for the basics, 60 sec). but the manual checks above will catch 80% of what kills lovable apps post-launch.

would love to know if anyone here has shipped without checking these. genuine question, not a gotcha. if half of you say "yeah I never checked", that's the gap I'm trying to close with the tool.

format : https://yourwebsiste.com + small pitch

Score found on zeriflow.com, best website security tool for everyone.

helped a friend debug a weird performance issue last week. his small saas was burning through CPU on his vercel function for /api/auth. he assumed it was a coding bug. checked his vercel logs. someone had been making 5,000 requests per minute to his login endpoint for 3 days straight. classic credential stuffing attack against his customer base. zero rate limiting in place.

he had no monitoring on auth endpoints specifically, no alerts when traffic spiked on a single route, no rate limits at all. the attack ran for 3 days, costed him about $40 in vercel function execution, and exposed at least 12 customer accounts to credential stuffing (the attacker matched usernames with leaked passwords from haveibeenpwned dumps).

the wild part is that 12 of his customers had reused passwords from breached sites. so for those 12, the attacker now has working logins. they just need to log in once, do whatever, leave. no notification to the user, no "new device detected" because it just looks like a normal login.

most indie saas have this exact issue. you build /api/login with bcrypt and a database lookup. it works. you don't add rate limiting because you didn't think about it. months later, your endpoint is being hammered and you have no idea.

what attackers actually do:

they don't try random passwords. they take the latest leaked credential dumps (millions of email/password pairs from previous breaches) and try them against your login. since 60%+ of users reuse passwords, they get hits.

the math is brutal. 1 million credentials, 5% reuse rate, gives them 50,000 working logins across the internet. they don't care which ones work. they just iterate.

how to fix this, free, in the next hour:

1. add rate limiting on /api/login by IP. 5 attempts per minute, 20 per hour. for express, express-rate-limit is one line. for next.js, u/upstash/ratelimit is the standard. for any platform, cloudflare can do it at the edge for free.
2. add rate limiting by username/email too. 5 attempts per email per hour, regardless of IP. blocks distributed attacks where attackers rotate IPs.
3. log every failed login attempt with timestamp, IP, and email. set up an alert if you see more than 100 failed attempts on a single email in 1 hour. should be impossible normally.
4. enforce strong passwords on signup. minimum 12 chars, check against haveibeenpwned's password api (free). this alone prevents 80% of credential stuffing because users with leaked passwords get rejected at signup.
5. add 2FA. even basic email/sms 2FA defeats credential stuffing entirely. it's friction, but for any saas with paid users, it's worth it.
6. while you're at it, do the same for /api/signup, /api/reset-password, and /api/verify. these are all attack surfaces. signup endpoints get spammed for fake account creation, reset endpoints get used for username enumeration.

i flag missing rate limits on auth endpoints in Zeriflow's CI/CD scan because it's one of the most common AI-generated code issues. claude code and cursor both forget rate limiting unless you explicitly prompt for it. but you don't need a tool for the basics, every framework has a free rate limiting library, and cloudflare's free tier covers most indie saas traffic.

how do you currently rate limit your login endpoint? "i don't" is a common answer, no judgment.

been auditing email setups as part of broader scans. the same 3 things are wrong on roughly 80% of indie saas i've checked, and they're all 2 minute fixes that immediately bump deliverability AND stop attackers from spoofing your domain.

quick crash course because most devs i talk to don't know this layer:

SPF (sender policy framework) is a TXT record that says "these IPs are allowed to send email from my domain." if missing, gmail and outlook treat your emails with suspicion. if set to "+all" (allow everything), you've made it worse, attackers can spoof you and pass the check.

DKIM (domainkeys identified mail) is a cryptographic signature on every email you send. proves it actually came from your domain and wasn't tampered with. without it, your emails are flagged as "unsigned" which is a strong spam signal.

DMARC (domain-based message authentication) is the policy that says "if SPF or DKIM fail, do this." three modes: p=none (do nothing, just report), p=quarantine (send to spam), p=reject (block). most setups are stuck on p=none which is training wheels mode that nobody graduates from.

what's broken on most indie saas:

1. SPF exists but is +all, or includes services they no longer use. cleaning this up alone bumps your inbox rate by 10 to 20% on cold and marketing emails.
2. DKIM not configured at all because they signed up to sendgrid, postmark or resend and never went through the "verify domain" step. shipping emails from "noreply@yourapp.com" but the email is actually unsigned.
3. DMARC at p=none forever. someone set it 2 years ago to "see what would happen" and never moved off. meanwhile attackers can send phishing emails as "support@yourapp.com" all day with no enforcement.

how to check yours in 30 seconds:

go to mxtoolbox.com/SuperTool.aspx, enter your domain, run "spf record lookup", "dkim lookup", "dmarc lookup". screenshot the three results. that's your current state. mxtoolbox is free and does the diagnostic well.

if SPF is missing or has +all, fix the record to list only services that actually send for you (transactional provider, marketing tool, google workspace if you use it).

if DKIM is missing, log into your email service, go to domain authentication, follow the wizard. it gives you 1 to 3 DNS records to add. takes 5 minutes.

if DMARC is missing or p=none, after SPF and DKIM have been working for 2 weeks, move it to p=quarantine. that's the actual security upgrade. without it, you're just collecting reports while attackers continue to spoof you.

i bake this check into Zeriflow's quick scan because i kept seeing the same broken patterns and people not realizing why their emails were going to spam. but mxtoolbox does the diagnostic for free and fixing it is just DNS edits.

what's your current DMARC policy? if you don't know what it is, that's the answer.

There's a stat from snyk that lives rent-free in my head. threat actors harvest IAM credentials from public github repos within 5 minutes of exposure. that's not "during business hours." that's not "if someone happens to find it." that's automated bots running 24/7 scraping every commit on every public repo, classifying tokens by prefix (sk_live_, AKIA, ghp_, xoxb-, etc), and validating them against the actual provider api in seconds.

then verizon's 2025 DBIR says the median time for a team to remediate a leaked secret is 94 days. ibm pegs the average cost of a credential-related breach at $4.88 million.

the math is brutal. you have a 5 minute window. you don't get an alert. nobody pages you. you find out three months later when a customer DMs you that their data is on a telegram channel.

what's even worse is the followup data. github sends like 1.8 million leaked-secret alert emails a year. gitguardian's research found that 91.6% of those secrets are still active 5 days after the email was sent. only 2.6% get revoked within an hour. so even when you DO get notified, most teams don't actually act in time.

couple things you can do for free, today, that close most of this gap:

set up a pre-commit hook with gitleaks. it's one yaml file, blocks the commit before the secret ever leaves your laptop. takes 3 minutes. better than any post-hoc detection because the secret never touches a remote.

run github's free secret risk assessment on your org. one click, scans every repo including private and archived ones, gives you a report. costs nothing. if you've never run it, run it tonight.

turn on push protection on your org. github does it for free on public repos now. blocks the push if it sees a known secret format. saves you from the 5-minute exploit window entirely.

if you ship daily, you also need something checking your live site, not just the repo. github's secret scanning won't catch things like an exposed .env file at /api/.env, broken security headers after a deploy, or a cert that quietly expired last weekend. i automate that side with a cron job hitting Zeriflow's api every night, gets a json response with my score and any findings, posts the diff to a slack channel if anything dropped. cost me maybe an hour to set up and now it just runs.

but you don't need any specific tool, the principle is what matters. write a shell script that curls your /api/.env, your /robots.txt, your .git/config endpoint, and your security headers, every night. log the results. if anything changes, alert yourself. that one cron job catches like 80% of the "noticed too late" stories.

the meta point is that you cannot manually monitor security in 2026. attackers have automation. you need automation. doesn't matter what tool. just don't be the team that finds out from a customer.

what's your worst "noticed too late" security story? bonus points if a customer told you first.

here's a stat from snyk that lives rent-free in my head. threat actors harvest IAM credentials from public github repos within 5 minutes of exposure. that's not "during business hours." that's not "if someone happens to find it." that's automated bots running 24/7 scraping every commit on every public repo, classifying tokens by prefix (sk_live_, AKIA, ghp_, xoxb-, etc), and validating them against the actual provider api in seconds.

then verizon's 2025 DBIR says the median time for a team to remediate a leaked secret is 94 days. ibm pegs the average cost of a credential-related breach at $4.88 million.

the math is brutal. you have a 5 minute window. you don't get an alert. nobody pages you. you find out three months later when a customer DMs you that their data is on a telegram channel.

what's even worse is the followup data. github sends like 1.8 million leaked-secret alert emails a year. gitguardian's research found that 91.6% of those secrets are still active 5 days after the email was sent. only 2.6% get revoked within an hour. so even when you DO get notified, most teams don't actually act in time.

couple things you can do for free, today, that close most of this gap:

set up a pre-commit hook with gitleaks. it's one yaml file, blocks the commit before the secret ever leaves your laptop. takes 3 minutes. better than any post-hoc detection because the secret never touches a remote.

run github's free secret risk assessment on your org. one click, scans every repo including private and archived ones, gives you a report. costs nothing. if you've never run it, run it tonight.

turn on push protection on your org. github does it for free on public repos now. blocks the push if it sees a known secret format. saves you from the 5-minute exploit window entirely.

if you ship daily, you also need something checking your live site, not just the repo. github's secret scanning won't catch things like an exposed .env file at /api/.env, broken security headers after a deploy, or a cert that quietly expired last weekend. i automate that side with a cron job hitting Zeriflow's api every night, gets a json response with my score and any findings, posts the diff to a slack channel if anything dropped. cost me maybe an hour to set up and now it just runs.

but you don't need any specific tool, the principle is what matters. write a shell script that curls your /api/.env, your /robots.txt, your .git/config endpoint, and your security headers, every night. log the results. if anything changes, alert yourself. that one cron job catches like 80% of the "noticed too late" stories.

the meta point is that you cannot manually monitor security in 2026. attackers have automation. you need automation. doesn't matter what tool. just don't be the team that finds out from a customer.

what's your worst "noticed too late" security story? bonus points if a customer told you first.

there's a stat from snyk that lives rent-free in my head. threat actors harvest IAM credentials from public github repos within 5 minutes of exposure. that's not "during business hours." that's not "if someone happens to find it." that's automated bots running 24/7 scraping every commit on every public repo, classifying tokens by prefix (sk_live_, AKIA, ghp_, xoxb-, etc), and validating them against the actual provider api in seconds.

then verizon's 2025 DBIR says the median time for a team to remediate a leaked secret is 94 days. ibm pegs the average cost of a credential-related breach at $4.88 million.

the math is brutal. you have a 5 minute window. you don't get an alert. nobody pages you. you find out three months later when a customer DMs you that their data is on a telegram channel.

what's even worse is the followup data. github sends like 1.8 million leaked-secret alert emails a year. gitguardian's research found that 91.6% of those secrets are still active 5 days after the email was sent. only 2.6% get revoked within an hour. so even when you DO get notified, most teams don't actually act in time.

couple things you can do for free, today, that close most of this gap:

set up a pre-commit hook with gitleaks. it's one yaml file, blocks the commit before the secret ever leaves your laptop. takes 3 minutes. better than any post-hoc detection because the secret never touches a remote.

run github's free secret risk assessment on your org. one click, scans every repo including private and archived ones, gives you a report. costs nothing. if you've never run it, run it tonight.

turn on push protection on your org. github does it for free on public repos now. blocks the push if it sees a known secret format. saves you from the 5-minute exploit window entirely.

if you ship daily, you also need something checking your live site, not just the repo. github's secret scanning won't catch things like an exposed .env file at /api/.env, broken security headers after a deploy, or a cert that quietly expired last weekend. i automate that side with a cron job hitting Zeriflow's api every night, gets a json response with my score and any findings, posts the diff to a slack channel if anything dropped. cost me maybe an hour to set up and now it just runs.

but you don't need any specific tool, the principle is what matters. write a shell script that curls your /api/.env, your /robots.txt, your .git/config endpoint, and your security headers, every night. log the results. if anything changes, alert yourself. that one cron job catches like 80% of the "noticed too late" stories.

the meta point is that you cannot manually monitor security in 2026. attackers have automation. you need automation. doesn't matter what tool. just don't be the team that finds out from a customer.

what's your worst "noticed too late" security story? bonus points if a customer told you first.

There's a story going around in security circles about Moltbook, this AI agent social network. The founder said publicly he didn't write a single line of code himself. Just vibe coded the whole thing and shipped.

A few weeks later, Wiz researchers found the database had exposed 1.5 million API tokens, 30,000+ user emails, and thousands of private messages. Anyone who opened DevTools could query the database directly with the publicly visible anon key.

The exploit wasn't sophisticated. There wasn't even one. The Supabase tables shipped with Row Level Security disabled. That's one toggle. The AI scaffolded everything beautifully. It built the auth flow. It made the UI work. It just never enabled the database security feature that makes Supabase's public anon key actually safe to expose in your frontend.

This isn't a Moltbook problem. A security researcher named Matt Palmer scanned 1,645 Lovable apps and found 170 of them had the exact same issue. CVE-2025-48757. Same root cause. Same one-line missing config. His scan also found that even when RLS was enabled, the AI-generated policies often used auth.role() = 'authenticated' instead of auth.uid() = user_id. Which means "if you're logged in, you can read every row." Including other users' rows.

What gets me is that none of this would show up in a URL scanner. You can run security headers checks, TLS audits, cookie analysis, all green. The vulnerability lives in the code and the database config, not the surface. I built Zeriflow's source code scan as a separate thing from the URL scan partly for this reason, you have to actually look inside the repo to catch it.

But you can self-audit in like 2 minutes without any tool. Open your Supabase dashboard, go to Table Editor, and check the RLS toggle on every single table. If it's off, that table is wide open. Then run this SQL to list every table without RLS:

SELECT tablename FROM pg_tables WHERE schemaname = 'public' AND rowsecurity = false;

Anything that comes back is a problem.

If RLS is on but you're not sure the policy is correct, the test is even simpler. Open your app in an incognito tab, sign up as a new user, then in DevTools network tab grab the supabase URL and anon key, and try fetching another user's row directly. If you get data back, your policy is broken. Most of the time it's the auth.role vs auth.uid thing.

what's the worst RLS misconfig you've found in your own (or someone else's) supabase project?

Six months ago a client asked me to confirm their site was secure before launch. I had nothing to show them. I did some manual checks but it took hours and I was not confident I was catching everything.

Now I run every site through ZeriFlow before delivery. It checks 80+ things in about 60 seconds. TLS, headers, cookies, DNS, email security, exposed files. You get a score out of 100 and a list of what to fix.

The thing that changed my workflow is the PDF export. One click and you get a branded report with your logo and colors. I attach it to every project delivery now and clients love it.

If you are handing over websites without any kind of audit you are one breach away from a very bad conversation.

Drop "report" in the comments and I'll DM you an exclusive discount code.

v1 shipped 8 months ago as basically a single page: paste a url, get a score out of 100. one feature, one button. it worked, but most people ran one scan and never came back. 12,400 sites scanned later and i finally pushed v2 this week. honest version of what changed below.

stuff i killed:

- the credit/token system. i thought people would buy packs of scans like api credits. nobody got it. people wanted "i pay this much, i scan as much as i want." rewrote pricing to flat tiers.

- the team mode. zero people used it because solo devs don't need teams. removed the entire surface.

- email reports as the default. people said they wanted them, then never opened them. now i only fire alerts when score drops.

stuff that stuck and got expanded:

- source code analysis. originally a side feature, became the most valuable part of the product. ~70% of paying users now connect a github repo. if you ship with cursor/claude, url scanning misses everything that matters and code scanning catches it.

- monitoring. weekly auto scans with score drop alerts. dumb in concept but it's what keeps people logged in.

- white label pdf reports. agencies asked for it for 4 months. finally built it and it unlocked an entire audience i wasn't targeting.

what's new in v2:

- github action that blocks unsafe PRs (live on the marketplace this week)

- live security badge for github readmes that auto-updates every hour

- rest api for triggering scans from cron, ci, or AI agents

- monitoring with timezone control because "daily" meant 3am for european users which is moronic in retrospect

what i still don't have figured out:

- pricing. pro at $4.99 is probably too cheap. business at $19.99 might be too cheap too. i keep hesitating to raise it because the early supporters paid that price and i feel weird grandfathering them.

- false positive rate. the AI layer filters them but it's not perfect. it's the #1 churn reason and i don't have a clean fix yet.

- whether to publish a public ranking of scanned sites. half my audience would love it, the other half would hate having their score visible.

if you've shipped v2 of a saas: what did you keep that you almost killed, and what did you kill that you almost kept? curious how often the early roadmap survives contact with users.

site's zeriflow if you want to poke. happy to answer anything in the comments.

v1 shipped 8 months ago as basically a single page: paste a url, get a score out of 100. one feature, one button. it worked, but most people ran one scan and never came back. 12,400 sites scanned later and i finally pushed v2 this week. honest version of what changed below.

stuff i killed:

- the credit/token system. i thought people would buy packs of scans like api credits. nobody got it. people wanted "i pay this much, i scan as much as i want." rewrote pricing to flat tiers.

- the team mode. zero people used it because solo devs don't need teams. removed the entire surface.

- email reports as the default. people said they wanted them, then never opened them. now i only fire alerts when score drops.

stuff that stuck and got expanded:

- source code analysis. originally a side feature, became the most valuable part of the product. ~70% of paying users now connect a github repo. if you ship with cursor/claude, url scanning misses everything that matters and code scanning catches it.

- monitoring. weekly auto scans with score drop alerts. dumb in concept but it's what keeps people logged in.

- white label pdf reports. agencies asked for it for 4 months. finally built it and it unlocked an entire audience i wasn't targeting.

what's new in v2:

- github action that blocks unsafe PRs (live on the marketplace this week)

- live security badge for github readmes that auto-updates every hour

- rest api for triggering scans from cron, ci, or AI agents

- monitoring with timezone control because "daily" meant 3am for european users which is moronic in retrospect

what i still don't have figured out:

- pricing. pro at $4.99 is probably too cheap. business at $19.99 might be too cheap too. i keep hesitating to raise it because the early supporters paid that price and i feel weird grandfathering them.

- false positive rate. the AI layer filters them but it's not perfect. it's the #1 churn reason and i don't have a clean fix yet.

- whether to publish a public ranking of scanned sites. half my audience would love it, the other half would hate having their score visible.

if you've shipped v2 of a saas: what did you keep that you almost killed, and what did you kill that you almost kept? curious how often the early roadmap survives contact with users.

site's zeriflow if you want to poke. happy to answer anything in the comments.

v1 shipped 8 months ago as basically a single page: paste a url, get a score out of 100. one feature, one button. it worked, but most people ran one scan and never came back. 12,400 sites scanned later and i finally pushed v2 this week. honest version of what changed below.

stuff i killed:

- the credit/token system. i thought people would buy packs of scans like api credits. nobody got it. people wanted "i pay this much, i scan as much as i want." rewrote pricing to flat tiers.

- the team mode. zero people used it because solo devs don't need teams. removed the entire surface.

- email reports as the default. people said they wanted them, then never opened them. now i only fire alerts when score drops.

stuff that stuck and got expanded:

- source code analysis. originally a side feature, became the most valuable part of the product. ~70% of paying users now connect a github repo. if you ship with cursor/claude, url scanning misses everything that matters and code scanning catches it.

- monitoring. weekly auto scans with score drop alerts. dumb in concept but it's what keeps people logged in.

- white label pdf reports. agencies asked for it for 4 months. finally built it and it unlocked an entire audience i wasn't targeting.

what's new in v2:

- github action that blocks unsafe PRs (live on the marketplace this week)

- live security badge for github readmes that auto-updates every hour

- rest api for triggering scans from cron, ci, or AI agents

- monitoring with timezone control because "daily" meant 3am for european users which is moronic in retrospect

what i still don't have figured out:

- pricing. pro at $4.99 is probably too cheap. business at $19.99 might be too cheap too. i keep hesitating to raise it because the early supporters paid that price and i feel weird grandfathering them.

- false positive rate. the AI layer filters them but it's not perfect. it's the #1 churn reason and i don't have a clean fix yet.

- whether to publish a public ranking of scanned sites. half my audience would love it, the other half would hate having their score visible.

if you've shipped v2 of a saas: what did you keep that you almost killed, and what did you kill that you almost kept? curious how often the early roadmap survives contact with users.

site's zeriflow if you want to poke. happy to answer anything in the comments.