DEV Community: Perufitlife

I shipped a live integration sandbox in 90 minutes instead of taking the partnership call. It changed the conversation.

Perufitlife — Tue, 12 May 2026 12:15:35 +0000

A CEO sent me a DM yesterday afternoon. Aviation learning platform. Wanted to talk about a partnership with my smaller aviation API (Rotatepilot — question banks, METAR decoder, airport lookups). Real founder, real platform, real intent.

I had two options:

Reply with my usual qualifying questions, schedule a 30 min call later in the week, do the meeting, agree on what to build, build it, send it for review, iterate.
Build it now and send the link.

I went with option 2. 90 minutes of work. The conversation flipped from "show me what this looks like" to "what's the commercial shape."

Here's how, and why I'll do this for every inbound partnership conversation from now on.

The DM that triggered this

From the CEO of SkyX International (aviation learning platform, Public Beta on Product Hunt):

"We are interested in your RotatePilot website, since it includes crucial tools that we think can help us develop a large selection of aviation tools. Your data bank (ATPL/PPL questions, API…) also fascinates us. We think a partnership between both platforms could benefit you and us. It could either be an API, embed, or any kind of licensing partnership. We are open and flexible. Before engaging into anything, I invite you to take a look at our platform, test out the features as you want, and feel free to give your suggestions."

Translation: "I want to integrate your API but I don't know what your API looks like yet, and you don't know what we'd actually consume."

The default founder-to-founder script here is:

"Great, here's a Calendly link, let's do 30 min."
On the call, you screen-share your API docs, they ask questions, you both end with "send me a sample integration."
You build the sample. You send it. They review. Maybe respond in a week. Maybe not.

I've done that loop probably 20 times in the last year. The conversion rate is awful. Most never come back. The ones that do, come back 2-3 weeks later by which time the energy has dropped.

What I did instead

Spent 5 minutes browsing their platform (onboarding.skyxintl.me). Took specific notes:

They list "structured learning pathways + spaced repetition" but no question bank size visible.
They list "METAR decoder" as a feature.
I didn't see a language switcher on the landing — looked English-only.
They're pre-launch (countdown timer at 00:00:00:00).

These are gaps where my API fills in. Not theoretical fit, actual fit, with specifics.

Then I built rotatepilot-skyx-sandbox — a single HTML file that hits four of my public REST endpoints live in the browser and renders the responses in a learning-platform style UI:

Question bank — GET /api/v1/question?subject=meteorology&count=2 — returns FAA-labeled MCQs with explanations.
METAR decoder — GET /api/v1/metar?icao=KJFK — returns decoded flight category, wind, visibility, cloud layers.
Airport lookup — GET /api/v1/airport/KSFO — returns name, ICAO, runways, training-airport flag.
Quiz of the day — GET /api/v1/quiz-of-day — returns one shared question for daily-engagement features.

The whole thing is one file. No build step. No backend. Calls go straight from the browser to my edge-served endpoints (CORS enabled, no auth tier needed at this volume). Open DevTools and you see the real requests.

Stack: ~300 lines of HTML/CSS/vanilla JS. Pushed to GitHub. Enabled GitHub Pages with gh api -X POST repos/.../pages -f "source[branch]=master". Live in 90 seconds.

Live demo — paste any ICAO, pick any subject, see real responses.

What I sent back to the CEO

Three messages, in order:

Qualifying questions — ranked top-2 pieces, format (API vs embed vs license), 6-month volume guess, commercial direction. Plus a 30-min call offer for later in the week if he preferred async.
Substantive feedback on their platform — what looked strong, three peer-pushback notes (the countdown timer reads 00:00:00:00, no product screenshot above the fold, Product Hunt badge buried in footer), and a concrete integration proposal direction.
The sandbox link — "Instead of waiting on the call to show what the JSON contract looks like, I went ahead and built the sandbox. It's a single static page that hits 4 endpoints live. Take a look when you have 5 min — would help us skip a lot of 'what does it look like' on the call and jump straight to commercial shape."

Total time: roughly 90 minutes of real work, including writing the messages and verifying the live endpoints.

Why this changes the conversation

The default partnership conversation has three rounds of friction:

Discovery — what do you have, what do we want.
Mapping — does the shape match, what would integration cost.
Commercial — how do we make money on this.

A sandbox collapses rounds 1 and 2 into a single artifact the other side can open and inspect on their own time. They don't need to wait for a meeting to understand the shape of what you have. You don't need to spend the meeting explaining endpoints. The meeting (if it happens) is just round 3, which is the only round that actually moves the deal.

It also forces you to do the work before you've gotten a "yes," which is exactly the work that makes the partnership real. Half the partnerships I've talked about never happened because the work to make them concrete never got done. Doing it on day zero filters out partners who weren't going to follow through anyway.

The general pattern

You don't need someone's permission to demonstrate value. The thing that's expensive isn't the meeting, it's the uncertainty between "we should partner" and "let's actually integrate." If you can collapse the uncertainty in 90 minutes of static-file work, do it.

This works for:

API-led partnerships — show your endpoints rendering in their kind of UI.
Embed/widget integrations — drop an iframe in a styled wrapper that resembles their site.
Data licensing — a quick HTML view of a sample of your dataset with proposed fields.
Cold outbound to a specific company — same idea, build a custom demo and lead with it.

It does not work for vague "let's chat" inbounds where the asker doesn't know what they want. That's a different problem (qualifying, not delivering).

The tools, for replicability

One HTML file. No framework.
git init && git add . && git commit && gh repo create --public --push
gh api -X POST "repos/USER/REPO/pages" -f "source[branch]=master" -f "source[path]=/"
Live URL: https://USER.github.io/REPO/

Source for the sandbox I built: github.com/Perufitlife/rotatepilot-skyx-sandbox.

What I'm doing with this pattern next: applying it to every cold outbound I send for my BaaS security auditors. Instead of "want a free scan?" → "here's a sandbox of what a scan of your project might find, formatted as a real audit report." Same effort, 10x higher conversion.

If you've shipped a sandbox-before-meeting and it worked (or didn't), I'd love to hear what you learned. Reply or DM.

I'm building a portfolio of single-purpose dev tools at github.com/Perufitlife. Latest: five open-source BaaS security auditors (Supabase, Firebase, PocketBase, Appwrite, Nhost) shipped this week.

I shipped a public Apify actor that scans Supabase projects for RLS leaks (took 90 min, found a 895-record leak on the first real test run)

Perufitlife — Tue, 12 May 2026 07:42:40 +0000

Just shipped a new public Apify actor: Supabase RLS Security Scanner.

What it does: paste your Supabase URL + anon key, get back a JSON report (plus a pretty HTML report) listing every table that's anonymously readable, with row counts and a curl reproducer for each finding.

Why this exists: the Supabase anon key is meant to be public — it ships in your frontend. The only thing keeping your tables private should be Row-Level Security. Across the 30 Supabase projects I scanned this week, ~10% had RLS forgotten on at least one user-data table (profiles, users, accounts, etc.). One I scanned this morning had 895 staff records with email + phone exposed to anyone with the public anon key.

What it costs: free to run on Apify free plan (cheap Apify compute). I'll publish per-scan pricing in the next update once the actor has 50+ runs of validation.

What it does NOT do: never reads row contents. Uses Prefer: count=exact + Range: 0-0 to confirm a leak exists without touching the data.

# Use it via API:
curl -X POST "https://api.apify.com/v2/acts/renzomacar~supabase-rls-scanner/run-sync-get-dataset-items?token=YOUR_APIFY_TOKEN"   -H "Content-Type: application/json"   -d '{
    "supabaseUrl": "https://YOUR-PROJECT.supabase.co",
    "anonKey": "eyJ...your-anon-key...",
    "outputFormat": "both"
  }'

Or the open-source CLI version (free, runs entirely on your machine):

npx @perufitlife/supabase-security --discover --url YOUR_URL --key YOUR_ANON_KEY

Output excerpt from a real scan I ran this morning:

{
  "findings": [
    {
      "table": "staff",
      "count": 895,
      "severity": "critical",
      "sensitiveColumns": ["email", "phone"],
      "reproducer": "curl '.../rest/v1/staff?select=*' -H 'apikey: ...' -H 'Prefer: count=exact' -H 'Range: 0-0' -I"
    }
  ],
  "summary": {
    "total_anon_readable": 3,
    "total_exposed_records": 895
  }
}

What I'm using this for:

My weekly scan service — rls-monitor.vercel.app ($29/mo) runs this against your project every week, alerts you the second a new leak shows up.
Free responsible-disclosure work — I'm offering free scans to the first 20 r/Supabase folks who DM me their URL this weekend (reddit post here). Inbound only — I don't scan projects without explicit permission from the owner.
Sister scanners are coming — Firebase, PocketBase, Appwrite, and Nhost versions all live as npm CLIs (@perufitlife on npm); the Apify-actor versions are next.

If this saves you from a real leak, please leave a review on the Apify store page. That's the engine that keeps me prioritizing this work.

Open-source repo + docs: github.com/Perufitlife/supabase-security-skill.

— Renzo

I scanned 30 Supabase repos this morning and found 3 production-grade leaks (one with service_role committed)

Perufitlife — Tue, 12 May 2026 07:19:55 +0000

TL;DR

This morning I ran a wider sweep of public GitHub repos that import @supabase/supabase-js and have anything resembling an anon key (or worse, a service_role key) in committed code.

Out of ~30 repos I probed (responsibly — counts only, no row contents), three had production-grade leaks:

A Chinese AI paper-writing tool with 1,669 stars and 1,843 user profile records readable anonymously.
Two indie-SaaS repos with the service_role key committed to .env.local — meaning anyone who finds the repo can read/write/delete every row in their database.

All three got responsible-disclosure pings (private email or GitHub issue) with a free DIY fix walkthrough + a paid turnkey option. We'll see what happens.

This post is about the method + monetization frame, not naming specific projects. If you want to scan your own project, the CLI is open source: @perufitlife/supabase-security.

The method (90 seconds per repo)

# 1. Fetch the file that imports createClient
curl -sL "https://raw.githubusercontent.com/<owner>/<repo>/main/path/to/file.ts"

# 2. Grep for hardcoded URL + key (most repos use env vars properly,
#    but ~10% commit a fallback or a .env.local for "convenience")
grep -oE 'https://[a-z0-9-]+.supabase.co'
grep -oE 'eyJ[A-Za-z0-9_-]+.eyJ[A-Za-z0-9_-]+.[A-Za-z0-9_-]+'

# 3. Probe common table names with the anon key — counts only, no data
curl -sLI "$URL/rest/v1/profiles?select=*"   -H "apikey: $KEY" -H "Authorization: Bearer $KEY"   -H "Prefer: count=exact" -H "Range: 0-0"   | grep -i "content-range"

# Output like: Content-Range: 0-0/1843
# Means: 1843 profile records readable by anyone with the anon key

That's it. No clever exploitation, no zero-days. Just: did the repo commit a key, is RLS on, what's the count.

What % of repos are leaking

Across the ~30 I tested today:

~10% had a hardcoded URL + working anon key. Most do this as a fallback in code (process.env.X || 'hardcoded').
~50% of those had RLS disabled on at least one user-data table (profiles, users, accounts, etc.).
2 had service_role keys committed. That's the catastrophic one — bypasses ALL RLS.

So the back-of-envelope hit rate for "find a real leak" is around 1-in-15 to 1-in-30 repos. Not high enough to spray-and-pray, but high enough that targeted searches (specific stacks, specific verticals) yield gold.

The monetization side

For folks building security tooling — the play I'm running:

1. Differential pricing by severity. A toy project hobbyist gets the free DIY walkthrough. A 1k-star app with paying Pro users gets pitched a $249 written audit + attestation. A B2B SaaS with service_role leaked gets pitched a $499-999 incident-response package.

2. Recurring monitoring upsell ($29/mo). One-time fix = $99. Continuous monitoring with weekly diff scans = $348/yr. The math favors recurring.

3. Bug bounty programs. Check HackerOne, BugCrowd, Intigriti for the target's name before doing free disclosure. Verified critical findings pay $500-10K. (None of my 3 today were on a bounty program.)

4. Vertical specialization. Healthcare app leaking patient data → HIPAA-adjacent compliance angle, different price tier. Finance app → PCI-DSS angle. Education → FERPA. Same scan, different anchoring.

5. Aggregated SEO posts (this one). Each scan batch becomes a post. Each post drives inbound. The compound is the brand, not the individual sale.

6. Stack expansion. Same pattern works on Firebase (firebase-security package), PocketBase, Appwrite, Nhost. We have all 5. Each new stack = new search surface area.

7. Cyber-insurance affiliate. Some insurers underwrite SaaS cyber policies and need risk signal pre-issue. Each verified leak finding can be sold as risk-assessment data ($50-200 per lead) to the right broker.

The ethical line I'm holding: never read row data, never publish identifying info pre-disclosure, always give a free DIY fix path. The paid offer is for the people who'd rather pay than learn the SQL. Both paths fix the leak. That's the actual goal.

What I'm doing next

Expanding the scanner search to Bolt + Lovable + Replit "vibe-coded" Supabase apps. Reddit reports 33% RLS issue rate on those. Lower-conversion targets (mostly toy projects) but easier to scale.
Same pattern on Firebase / PocketBase / Appwrite. Already have the scanners (Perufitlife on npm).
Weekly RLS Monitor — $29/mo that re-scans your project and alerts you on the first new leak. rls-monitor.vercel.app.

If you've shipped a Supabase project to production and never explicitly written RLS policies on every table, you are most likely in the ~50% that leaks. Free CLI scan takes 5 minutes: npx @perufitlife/supabase-security --discover (your keys never leave your terminal).

If you'd rather pay someone to do the audit + write the policies turnkey, $99 (one-time): stripe link.

— Renzo (perufitlife on GitHub / npm)

I expanded my niche AI factory from 9 to 15 generators in under an hour

Perufitlife — Tue, 12 May 2026 06:24:31 +0000

Yesterday I wrote about a 2-hour panic-build: 9 niche AI generators shipped on one factory backend after 24h of $0 sales on a generic humanizer. (previous post)

Today I extended that factory from 9 to 15 generators in under an hour. Not because I think 15 is the right number — because the marginal cost was so low it'd be irrational not to keep planting.

The 6 I added

All at aitells.vercel.app/<slug>:

/thank-you-note — gifts, weddings, post-interview, sympathy. Names the specific gift, 80-130 words.
/breakup-text — firm + kind, names what's ending, one real reason, no "let's stay friends" unless requested.
/instagram-caption — first-line hook readable before "more", one specific detail, 5-8 mixed hashtags (not 30).
/linkedin-post — no "I'm humbled to announce", first-line hook, one concrete claim + one specific story or number.
/reference-letter — 2-3 specific examples with outcomes, one honest growth area framed as context.
/out-of-office — clear dates, response expectations, backup contact, no double "in my absence".

Each is free preview → $9 one-time unlocks all 15 generators plus the rewriter.

The cost of generator #15 vs #1

Generator #1 (eulogy) took me about 2 hours: building the factory, the reusable client component, the Stripe gate, the template structure.

Generator #15 (out-of-office) took 12 minutes:

Add one Template object to /api/generate/route.ts (~30 lines: systemPrompt, buildUserPrompt, maxTokens, previewWords).
Create one page.tsx with <GeneratorClient templateId="..." fields={[...]} /> and a metadata block.
Add the URL to sitemap.ts and a card to the homepage hub.
Deploy. Smoke test. IndexNow ping.

The bottleneck is no longer code. It's knowing which niche is worth shipping.

How I pick the next niche

After a day of staring at this, my heuristic is:

Single-purpose Google query exists. Someone searches "ai apology letter" or "ai wedding toast". The verb is bounded.
Pain has a deadline. Wedding next month, funeral this week, performance review due Friday. Generic tools don't compete because urgency burns through indecision.
The output is too important to half-ass and too small to hire a professional for. $9 is cheaper than 2 hours of your time. A pro freelancer is $200.
The buyer doesn't want to share that they used AI. Apology letter, breakup text, eulogy, college essay. They're not going to subscribe to your newsletter and tweet about you. One-time payment, no friction.

Out of these 15, the ones I'm betting are the strongest on this rubric: eulogy, best-man-speech, apology-letter, breakup-text, college-essay. The rest are surface-area bets.

The architecture (now with 6 more templates)

/api/generate/route.ts                  ← 15 templates in one TEMPLATES dict
  POST {template_id, inputs} → {ok, preview, full, word_count}

/_generators/GeneratorClient.tsx        ← one reusable client component
  takes {templateId, title, subtitle, fields[], pricePill, ctaPrice}
  renders form → POST /api/generate → preview → Stripe CTA if not paid

/eulogy/page.tsx                        ← 30 lines
/breakup-text/page.tsx                  ← 30 lines
/out-of-office/page.tsx                 ← 30 lines
... etc x 15

Adding a 16th niche right now is a 10-15 minute job. The interesting thing isn't the code — it's that the incremental risk is also tiny. If one niche flops, it lives at /<slug> forever earning $0 with negligible token cost. If one hits, I have the infra to add 5 cousins to it in an afternoon.

What's not done

Cross-device unlock. The aitells_lifetime flag is in localStorage. Buy on phone, can't use on laptop yet. Fixing this with a Supabase table + magic link after I hit 5 sales — not before.
A/B testing different price points. Single $9 Stripe link for now. Will add $7 / $9 / $14 splits after first sale to learn elasticity.
Brand-safe variants. Right now the LinkedIn-post generator outputs my preferred style (direct, slightly contrarian). Some users want corporate-LinkedIn-speak. Future field.
Search Console traction signal. New URLs go live → IndexNow pings → Bing/Yandex pick up first → Google indexes in 1-3 weeks. ChatGPT/Perplexity citations come last (4-8 weeks). I'll know in mid-June whether the factory thesis is right.

Honest revenue check

15 generators live. $0 in sales as of writing. I'm 36 hours into this approach. The cost has been near-zero (Vercel free, Anthropic tokens ~$0.30 total so far for testing all 15 endpoints).

If even ONE generator gets first-page Google in 4 weeks, I'm in the money. If three of them do, I'll ship 30 more.

The factory: aitells.vercel.app — the header has cards for all 15.

Cross-pollinating with my BaaS auditor work too — same factory pattern: one supabase-security core, package 5 ways. Different domain, same compounding logic.

If you've shipped niche AI wrappers and can share how indexation went for you — drop a comment. Especially curious about people in the 4-12 week SEO range with similar one-purpose URLs.

I shipped 9 AI niche generators in 2 hours after my generic SaaS got 0 sales (the factory pattern)

Perufitlife — Tue, 12 May 2026 06:17:32 +0000

After 24 hours of trying to sell a generic "AI text humanizer" (0 sales), I sat down and did what I should've done first: looked at what's actually selling in indie SaaS land.

I scraped a GitHub list of 373 micro-SaaS that are running today. Read the descriptions. Looked for the pattern.

The pattern that wins: one specific use case, one specific pain, one $9-$19 transaction. Not "AI text humanizer" (too generic, who's the buyer?). Specific things like:

AI Wedding Toast
AI Cover Letter Generator
AI PowerPoint Maker
AI Apology Letter
AI Eulogy Generator

The buyer has a wedding next month. A funeral this week. A job application due Sunday. They Google "ai eulogy generator", land on something that asks 5 specific questions, get a usable speech, hit the $9 button. Done.

I'd been building "aitells — AI text detector + humanizer" for 24h and gotten zero buyers. Today I sat down and shipped 9 single-purpose generators on top of the same backend, in 2 hours total.

What I shipped

All at aitells.vercel.app/<name>:

/eulogy — funeral speech in 30 seconds, 3-4 min spoken
/best-man-speech — wedding toast that gets the room
/wedding-toast — maid of honor, father of bride, etc.
/apology-letter — the kind that lands, no "sorry if you felt"
/resignation-letter — close the door cleanly
/performance-review — concrete, no "wears many hats" word soup
/cover-letter — past the first sentence
/college-essay — Common App, voice of a 17-year-old
/tinder-bio — right-swipe hooks

Each is free preview → $9 unlock-everything (one Stripe link unlocks all generators + the rewriter on the same site).

The architecture (under 80 lines of repeated code per generator)

The pattern:

/api/generate/route.ts                  ← one factory endpoint
  TEMPLATES = { "eulogy": {...}, "best-man-speech": {...}, ... }
  POST {template_id, inputs} → {ok, preview, full, word_count}

/_generators/GeneratorClient.tsx        ← one reusable client component
  takes {templateId, title, subtitle, fields[]} as props
  renders form → POST /api/generate → render preview → Stripe CTA if not paid

/eulogy/page.tsx                        ← 30 lines, mostly props
  <GeneratorClient templateId="eulogy" title="..." fields={...} />

Adding a 10th generator is: write one Template object in the factory, write one page.tsx with the field list, deploy. About 20 minutes.

Why this works (theory of the case)

The chatgpt.com referrer signal: when someone asks ChatGPT "I need help writing X", ChatGPT either writes it inline OR recommends a tool. For ChatGPT to recommend you, you need:

A clean, narrow URL: aitells.vercel.app/eulogy beats aitells.vercel.app/?type=eulogy
SEO metadata that says exactly what you do
JSON-LD SoftwareApplication schema (already on the homepage, propagating)
Real text content explaining the differentiation, not just a form

I shipped 9 narrow URLs in one afternoon. In 4-8 weeks, Google will index them and ChatGPT/Claude/Perplexity will start citing them. Until then, IndexNow pinged Bing/Yandex for faster discovery.

What I'm watching now

Stripe for the first $9 buy
Google Search Console for impressions per landing (in 2-3 weeks)
ChatGPT referrer signups (the leading indicator that the niche pages got picked up)

If even 2 generators get traction, I'll ship 20 more in 5 hours. The factory is built. The only marginal cost per generator is the AI tokens for that one buyer's preview + full speech (~$0.02), plus 20 min of my time.

The honest postmortem on the first 24h

Six hours yesterday went into a generic "AI text humanizer". It still works. It still has $0 in sales. The market was telling me the offer was too generic. I kept polishing instead of pivoting.

When the market gives you a 0, the answer is rarely "do the same thing better". It's "do a much more specific thing".

I also build supabase-security and 4 sister BaaS auditors. Same factory pattern: build one core, package 5 ways. Works for SaaS just like it works for content generators.

The factory: aitells.vercel.app (lists all 9 generators in the header).

I shipped 5 things around my product in 90 minutes — MCP server, GitHub Action, 3 SEO landings

Perufitlife — Tue, 12 May 2026 05:44:56 +0000

I shipped aitells (free AI text detector + paid humanizer) yesterday. Today I shipped 5 more things around it in about 90 minutes. Sharing because each is a small, reusable distribution play that compounds.

1. MCP server (npm published, GitHub repo)

→ @perufitlife/aitells-mcp · github.com/Perufitlife/aitells-mcp

Claude Code, Cursor, and any MCP-compatible client now get detect_ai_tells and humanize_text as native tools. Configure once, ask the model "humanize this LinkedIn post in my voice" and it picks the right tool.

Implementation is 100 lines of TypeScript wrapping the existing aitells public API. The win isn't the code — it's that the MCP ecosystem has its own discovery channels (Glama.ai, awesome-mcp-servers, etc.) and a different audience than the web app.

{
  "mcpServers": {
    "aitells": {
      "command": "npx",
      "args": ["@perufitlife/aitells-mcp"]
    }
  }
}

2. GitHub Action (marketplace listing)

→ github.com/Perufitlife/aitells-action

Scans PR titles, bodies, and commit messages for em-dashes, "delve", parallel bullets, etc. Posts a friendly summary comment on every PR.

- uses: Perufitlife/aitells-action@v1
  with:
    target: both
    fail-on: 65    # block merge if humanness < 65
    comment: true

Same idea as the MCP server — wrap the existing API in a different package format to hit a different audience (engineering teams that care about keeping their PR history sounding human).

3-5. Three competitor SEO landings

Each one is a Next.js page with metadata + canonical URL + a shared _vs/client.tsx component that does live detection on whatever text the user pastes. The differentiation argument is in the page copy. Templated, took ~30 min total for all three.

People searching "zerogpt vs..." have buyer intent. That search has high commercial value for low effort.

The meta pattern

I had one product (aitells.vercel.app). I now have 6 entry points to it: the web app, MCP server, GitHub Action, and 3 SEO landings. Plus the existing Dev.to articles and GitHub profile README and cross-links from other repos.

The actual code under all of these is the same /api/detect and /api/rewrite endpoints. Everything else is packaging the same core for a different audience.

Building takes hours. Packaging takes 30 minutes per format. If your product solves a real problem (and AI text leaking through review pipelines is a real problem), the bottleneck isn't building more features — it's getting the existing thing in front of the audiences that don't know your URL.

I also just published the public API docs so anyone can integrate the raw endpoints in their own product. The detector is free forever. The humanizer is $19 lifetime, first 100 buyers only, then $49/mo.

If you want to use it as an MCP server: npm install -g @perufitlife/aitells-mcp and follow the config snippet above.

I also build supabase-security and sister BaaS auditors. Same pattern: build the tool, then package it 6 ways. The pattern works.

I found 3 silent revenue-leaking bugs in my SaaS in 45 minutes (and the meta-lesson)

Perufitlife — Tue, 12 May 2026 05:18:14 +0000

I run a small aviation SaaS ($45 MRR, 3 paying customers, 75% churn). This morning I decided to actually look at my data instead of write more code. In 45 minutes I found three silent revenue-leaking bugs. Sharing each one because they're the kind of stuff every indie SaaS has and never notices.

Bug 1: cron silently returned 0 candidates for 6 weeks

I had a winback cron (/api/cron/winback) that emails canceled subscribers at day 7, 21, 45 after they cancel. The Supabase query:

const { data: subs, error } = await supabase
  .from("subscriptions")
  .select(`user_id, status, tier, current_period_end, updated_at, created_at, ...`)
  .eq("status", "canceled")
  .gte("updated_at", new Date(Date.now() - 60 * 86400000).toISOString());

Problem: the column is canceled_at, not updated_at. The Supabase JS client returned { error: 'column does not exist' }, the cron caught it and quietly returned an empty array. Every day for weeks, "0 candidates, 0 emails sent, exit 0". No alarm.

I caught it because I ran SELECT COUNT(*) WHERE winback_pulses_sent IS NOT NULL and got 0 across 51 premium-tagged profiles. Then I read the cron source.

Lesson: anywhere your code does if (error) return [], log the error first. Silent failure is the worst failure mode in marketing automation because users don't bounce — they just never hear from you.

Bug 2: webhook never wrote the timestamp it was supposed to

Same subscriptions table. 14 rows with status='canceled' and canceled_at = NULL. Stripe knew when each cancellation happened, my webhook just never stored it.

Looking at the webhook:

case "customer.subscription.deleted": {
  if (sub) {
    await supabaseAdmin
      .from("subscriptions")
      .update({ status: "canceled" })  // ← no canceled_at here
      .eq("user_id", sub.user_id);

    // ... later, inside a try block ...
    try {
      // ... other side effects ...
      await supabaseAdmin
        .from("subscriptions")
        .update({
          cancellation_reason: cancelReason,
          cancellation_feedback: cancelFeedback,
          canceled_at: new Date().toISOString(),
        })
        .eq("user_id", sub.user_id);
    } catch (err) {
      // swallow
    }
  }
}

canceled_at was only set inside a try block alongside other side effects. If any of the side effects failed (which it apparently did, since 14/15 rows had NULL), the whole try aborted and canceled_at never got written. The first .update() was the only one guaranteed to run, and it didn't include canceled_at.

Fix: move the timestamp to the unconditional update.

.update({ status: "canceled", canceled_at: new Date().toISOString() })

Then backfilled 15 historical rows from Stripe's canceled_at via the Stripe API + Supabase REST PATCH.

This bug compounds the first one: even with the cron fixed, it would've found 0 candidates because the column it filtered on was NULL across all historical cancels.

Bug 3: filter that worked on day 1 broke as data accumulated

Recovery cron for abandoned checkouts. Pulls Stripe sessions in status='expired' from last 48h, then filters out anyone who "already paid". The filter:

const { data: activeProfiles } = await supabaseAdmin
  .from("profiles")
  .select("email, subscription_tier")
  .neq("subscription_tier", "free");

Intent: "don't bother people who already converted". Implementation: filter by subscription_tier column in profiles.

Reality: 51 profiles in my DB had subscription_tier = 'premium' from past subscriptions that had since canceled. The webhook bug above meant their tier wasn't downgraded to free when they canceled. So when a new abandoned-checkout user shared an email with one of those 51 zombie profiles, the cron silently skipped them.

Result: cron output said {"total_abandoned": 11, "sent": 0, "skipped": 11} every day. Looks like the system is working ("no abandoned checkouts to recover today"), is actually broken.

Fix: derive the "already paid" set from subscriptions.status='active', not from profiles.subscription_tier. The subscriptions table is what Stripe writes, the profiles tier was a denormalized convenience that drifted.

What I shipped after finding all three

Winback cron fix → 8 emails to real canceled customers immediately (1 of them at pulse 3 = 60% off final offer)
Webhook fix → future cancels populate canceled_at correctly
Recovery cron fix → next run will pulse 11 abandoned-checkout emails in pipeline
Manual final-shot to 5 maxed-out abandoned-checkout leads (60-cent customs in Resend)
Backfilled 15 historical timestamps from Stripe API

Total emails out from those 45 minutes: 14, all with WINBACK60 coupon (60% off 3 months). Worst case: nobody converts and I learned my data flow. Best case: even 2 conversions = +$30 MRR which is 66% growth on a $45 baseline.

The meta-lesson

I had been writing more features all week. Adding more cron jobs. More email templates. More variants. None of it would have helped because the actual pipes were leaking. Sometimes the highest-leverage 30 minutes you can spend is just SQL-querying your own database.

If you run a small SaaS: try SELECT status, COUNT(*) FROM subscriptions GROUP BY status and reconcile it against your Stripe dashboard. If those don't match, you have at least one of the three bugs I had.

I also build aitells.vercel.app (free AI text detector + paid humanizer) and supabase-security (open source RLS auditor). Both built after I got bitten by the problem they solve. Same pattern.

How I shipped the rewriter side of an AI tell detector in 30 minutes (Claude + Next.js + Vercel)

Perufitlife — Tue, 12 May 2026 03:12:19 +0000

Yesterday I shipped a free detector for the 12 most reliable AI writing fingerprints. The story behind it: my reddit account got 2 public "all comments are AI generated" callouts in one day. Mods removed 3 posts. I was running everything through Claude. The em-dashes and "delve" gave me away in seconds.

Detector traction was fine. 100+ scans day one, sat at 12 page views from a Dev.to post overnight. But every single piece of feedback I got was the same: "ok cool, now how do I fix it without rewriting by hand every time?"

So I shipped the rewriter today.

→ https://aitells.vercel.app/rewrite

what it does, technically

You paste two things:

Your AI-generated text (the thing you would post)
1-3 writing samples of how you actually write (old reddit comments, tweets, emails)

The endpoint sends both to Claude with a strict system prompt that hard-bans em-dashes, "delve", "tapestry", "navigate the X", "in conclusion", "however,", parallel bullet structure, uniform sentence length, and 9 other patterns from the detector ruleset.

The samples are critical. Without them you get generic "casual reddit voice" output which is fine but not yours. With them, you get sentence rhythm matched to how you actually type. Lowercase if you lowercase. Typos and fragments allowed if your samples have them. Slang preserved.

why it's different from "AI humanizer" tools

Most of those just re-prompt GPT to "write more naturally". You end up with slightly different AI text. Same em-dashes, same "delve", same parallel bullets. They fail Reddit moderation the same way the original did.

This one is built on top of the detector. The system prompt enumerates the exact patterns the detector flags. Output that still trips the detector defeats the purpose, so the constraints are explicit.

tech stack, since you asked

Next.js 14 App Router, edge route for the detector, nodejs runtime for the rewriter (Anthropic API was blocking edge IPs)
Claude Sonnet 4.6 via the messages API
No database. localStorage tracks the free-tier counter. Email gets pushed to Resend for the list.
Stripe Payment Link for the $19 lifetime tier. No webhooks yet, manual fulfillment until volume justifies.

The whole thing is 3 files, deployed on Vercel hobby tier.

what's broken / shipping next

No Stripe-gated unlimited path yet. After purchase I send the customer a permanent email token by hand. Will automate it once I see 5 sales.
Detector and rewriter are decoupled. I want a single workflow: scan, see flags, click "rewrite this", get the output rescored. Shipping that this week.
The detector rule set is closed for now. Will open-source once it stabilizes past v0.5.

try it

If you ship AI-generated reddit comments, cold emails, tweets, or LinkedIn posts and your engagement is mysteriously bad, paste your last 3 outputs into the detector. The score is real and the highlighted patterns are reproducible.

If they all score below 60, you need the rewriter.

aitells.vercel.app/rewrite

Free first rewrite. $19 lifetime if you want it forever. First 100 buyers only, then it goes to $49/mo.

Built by @Perufitlife. Also shipped a Supabase security auditor recently after finding 14 critical leaks in my own CRM. Same pattern: build the thing you wish existed when you got bitten.

I built a free AI tell detector after my own Reddit account got 2 'all comments are AI generated' callouts in one day

Perufitlife — Tue, 12 May 2026 02:51:48 +0000

In 24 hours my Reddit account picked up:

3 ModTeam removals
2 public callouts of "all comments are AI generated"
1 "Calm down with your AI responses. Your credibility goes down hard if you can't formulate sentences on your own"

I was running everything through Claude. Clean writing. The mods spotted it in seconds.

So I sat down and mapped the patterns.

the 12 most reliable AI tells

em-dash (â€”). The single strongest tell. Real people on Reddit use commas and periods. AI loves the em-dash.
"delve". Just don't.
tapestry / realm / landscape / journey / venture / endeavor. Metaphor cluster nobody actually types.
"navigate the X", "unlock the X", "harness the X". Verb-noun combos.
"Great question", "Absolutely", "100%", "Exactly this" as standalone openers.
"In conclusion", "In summary", "Ultimately,". Essay closers in casual writing.
buzzword cluster: leverage, robust, seamless, holistic, streamline, ecosystem. One is fine. Three in a paragraph reads AI.
parallel bullet structure. All bullets the same length, all starting with the same verb form. Humans write uneven lists.
tricolon rhythm: "X, Y, and Z" lists repeated.
uniform sentence length. Humans write some short, some long. AI averages out.
Title Case headings in informal comments.
"However,", "Moreover,", "Furthermore," sentence openers. Humans use "but" and "also".

I put all of this behind a free in-browser detector. Paste your AI text, see every flag highlighted, fix before posting.

â†’ https://aitells.vercel.app/

No login, no auth.

update: the rewriter just shipped

Detection is half the problem. After 100+ scans on day one, the question I kept getting was: "ok now how do I fix it without rewriting everything by hand?"

So I shipped the rewriter today.

→ https://aitells.vercel.app/rewrite

How it works: paste your AI text, paste 1-3 samples of how you actually write (old reddit comments, tweets, emails), and it strips the fingerprints while matching your voice. No em-dashes ever. Bullet symmetry broken. Varied sentence length. Lowercase if you lowercase.

Most "AI humanizer" tools just re-prompt GPT to "write more naturally" which still produces AI text. This one runs the same 12-rule detector against the output. If your samples are real, the rewrite reads like you.

First rewrite is free with your email. $19 lifetime if you want unlimited.

why this might help

If you ship Reddit comments or cold emails written by AI and your conversion is mysteriously bad, this is probably part of it. Detection is more aggressive every month. The fix isn't "stop using AI to write" - the fix is removing the fingerprints.

I'm shipping more rules daily. Open to suggestions if you have a tell I missed.

Source for the detection rules: https://github.com/Perufitlife (will open-source the rule set once it stabilizes).

Also built a Supabase security auditor recently after finding 14 critical leaks in my own CRM: https://perufitlife.github.io/supabase-security-skill/

Same pattern: build the thing you wish existed when you got bitten.

I shipped 5 BaaS security auditors in one day — keyless `npx --discover` mode for Supabase, PocketBase, Appwrite, Firebase, and Nhost

Perufitlife — Mon, 11 May 2026 12:33:02 +0000

The story

A week ago I built supabase-security, a small Node.js auditor that scans Supabase projects for over-permissive RLS policies. To test it, I scanned 100 random Supabase projects from GitHub.

22 out of 100 leaked user data anonymously. The pattern was consistent: dashboard says "RLS enabled ✅", policies say USING (true), anonymous curl returns the full table.

Then I ran the tool against my own production CRM (FitCRM, an e-commerce ops platform I've been running for 2 years). Found 14 critical leaks. Order tables open to anon. Storage buckets with predictable signed URLs. RPCs with SECURITY DEFINER bypassing RLS.

I wrote the postmortem yesterday.

After that, two thoughts:

If this many random Supabase projects leak, what about every other BaaS?
The "keyless" mode (parse repo + probe anon, no admin creds) is the magic — anyone can run it on any project, including ones they don't own.

What I shipped today

Five sister tools. All MIT, all on npm, all use the same --discover pattern:

1. supabase-security v0.4

npx supabase-security@latest --discover .

Parses from('table') / rpc('function') / storage.from('bucket') call sites, extracts SUPABASE_URL + SUPABASE_ANON_KEY from your repo, then probes the public REST API anonymously. Flags any table that returns rows.

2. pocketbase-security v0.2

npx pocketbase-security --discover .

Parses pb.collection('name') call sites, then hits /api/collections/{name}/records anon. Catches the legendary PocketBase footguns: empty rules (= fully public), @request.auth.id != "" (any signed-up user passes), || true leftover dev rules.

3. appwrite-security v0.2

npx appwrite-security --discover .

Parses databases.listDocuments(dbId, collId), probes /v1/databases/{db}/collections/{coll}/documents anon. Flags collections with the any role on Read permission, or users role with document security OFF.

4. firebase-security v0.2

npx firebase-security --discover .

Parses collection(db, 'x') / doc(db, 'x/y'), extracts projectId from firebase config or env, then GETs firestore.googleapis.com/v1/projects/{pid}/databases/(default)/documents/{collection} anon. Confirms the legendary if true / wildcard-match-all leak pattern.

5. nhost-security v0.2

npx nhost-security --discover .

Parses gql`queries for table names, auto-resolves the Hasura endpoint from subdomain+region (or env), POSTs anonymous queries against/v1/graphql. Flags tables where theanonymous` role has SELECT with permissive row filter.

The common pattern across every BaaS

Every BaaS has the same trap:

BaaS	Footgun	Dashboard says
Supabase	`USING (true)` on RLS policy	"RLS enabled ✅"
PocketBase	Empty rule string	"Public" (in tiny text)
Appwrite	`any` role on Read	Permissions "configured"
Firebase	`allow read: if true`	"Test mode"
Nhost	`anonymous` role with `{}` filter	"Permission configured"

In every case, the dashboard makes the configuration look intentional. In every case, anonymous curl returns rows. The dashboards don't show you what an anonymous-role evaluation actually returns — only what your role (the developer, signed in) returns.

Why "keyless --discover" is the unlock

Traditional security audits need admin credentials. The dev says "audit my Supabase" and hands you a service-role key. That's a high-trust ask and creates friction.

The keyless mode flips it:

Run npx <stack>-security --discover . from any project directory
It reads your client code (which already knows what tables/collections/buckets exist)
It probes the public API with the same anonymous credentials anyone on the internet has
No admin auth, no key sharing, no install

You can run it against your own project before pushing, or against a friend's project they're worried about, or in a CI step.

Patterns I'd add next

Things I want to detect but don't yet:

Cross-platform: Same project using Supabase + Stripe + Resend — credential leak in one breaks all three. Need a unified scanner.
JWT signature secrets committed to repos (already detectable via gitleaks but I want the BaaS-specific impact analysis)
Storage paths with predictable signed URLs — the FitCRM case
Function call sites with SECURITY DEFINER bypassing RLS — PostgREST anti-pattern
GraphQL introspection on Hasura instances exposing schema

Try it

Pick the stack you use most. The discover mode runs in seconds:

`bash cd your-project npx supabase-security --discover . # or pocketbase-security, etc `

If you have a project worth a deeper audit, the paid $99 single-tenant audit report includes the manual review I did on my own CRM that found the SECURITY DEFINER RPCs and the predictable bucket paths. But the free CLI catches the common 70% of leaks.

I built a Supabase security tool, then found 14 critical leaks in my own production CRM

Perufitlife — Mon, 11 May 2026 11:29:47 +0000

I've been working on an open-source security auditor for Supabase projects for the last few weeks (supabase-security on npm, MIT licensed, ~4k weekly downloads). Probes anonymously to find RLS gaps, public storage buckets, SECURITY DEFINER functions exposed to anon, that kind of thing.

This morning I shipped a new feature: a --discover mode. Keyless — it walks your local repo, pulls every table / RPC / bucket reference from .from() / .rpc() / .storage.from() call sites, then probes only the surface your app actually uses with the public anon key. No PAT, no admin token, no signup.

Before announcing it, I wanted to run it against my own production CRM as the final QA test. Worst case it finds zero issues and I look smart.

It found 14 critical leaks

7 tables that returned actual rows to anonymous callers (couriers, bot_knowledge_base, product_variants, zone_stats, etc — internal business data)
6 SECURITY DEFINER functions that anyone with my public anon key could execute (get_dashboard_stats, get_courier_stats, get_historical_daily_stats — basically the entire reporting surface, all callable without auth)
2 storage buckets that anon could list

The pattern

Every single one had RLS technically "enabled" on the Supabase dashboard. Every SELECT policy was USING (true) applied to roles {-} (which in Postgres means "all roles", anon included).

-- What I found via pg_policy:
polname                          | polcmd | roles | using_expr
couriers_select                  | r      | {-}   | true
bot_knowledge_base_select        | r      | {-}   | true
product_variants_select          | r      | {-}   | true
-- ...and 4 more

Server-side reads use service_role (which bypasses RLS), so nothing internal broke. Client-side reads were never wired up either. The only callers were... anyone on the internet, since the anon key sits in every JS bundle the moment someone opens devtools.

The fix

DROP POLICY IF EXISTS couriers_select ON public.couriers;
CREATE POLICY couriers_select ON public.couriers
  FOR SELECT TO authenticated USING (true);
-- repeat 6x

REVOKE EXECUTE ON FUNCTION public.get_dashboard_stats() FROM anon, public;
GRANT  EXECUTE ON FUNCTION public.get_dashboard_stats() TO authenticated;
-- repeat 5x

Applied via the Management API since local migrations were out of sync with prod. Re-ran the audit. 14 → 0.

What I keep thinking about

The dashboard "RLS enabled" checkmark is misleading. It tells you nothing about who can actually read what. Until you fire an HTTP request with the public anon key and inspect the response, you're guessing.

Tools that don't catch yourself aren't done. I had written the check for this exact pattern six weeks ago, and was still vulnerable. Static analysis of migrations alone misses it — the SQL looks fine. You need to actually probe.

The under-priced risk on Supabase right now is RPC functions with SECURITY DEFINER + EXECUTE granted to anon. Most scanners don't look at the RPC surface. Mine had 6 open. Several leaked admin-flavored data.

Try it on yours

npx supabase-security@latest --discover .

MIT licensed, findings stay on your machine, no signup. Repo on GitHub.

First time the tool felt like it was actually pulling its weight was when it pointed back at me. Mildly humbling.

If you ship on Supabase, please run this. The 22% figure I quote in the longer blog post about scanning 100 random projects is real, and I now know first-hand that "I'm careful with RLS" isn't a defense.

I scanned 35 random Firebase projects from GitHub. 23% leak user data anonymously.

Perufitlife — Sat, 09 May 2026 15:29:39 +0000

I picked 35 random Firebase project IDs from public GitHub repos this morning and probed each for publicly readable Firestore collections. No auth, no special tools — just plain GET requests to firestore.googleapis.com.

8 of them — 23% — returned data to an anonymous request.

Here's the raw breakdown:

Collection	# of projects leaking
`users`	4
`products`	3
`posts`	2
`messages`	1
`profiles`	1
`orders`	1

12 leaks across 8 projects in a 35-sample slice.

How is this possible?

Firebase apps bundle a firebase-config.js into every web build. That config contains the project ID. The project ID is not secret — it's in the URL, in the JS bundle, in any .env.example somewhere. The actual security boundary is your firestore.rules file.

If your rules look like this:

service cloud.firestore {
  match /databases/{database}/documents {
    match /{document=**} {
      allow read, write: if true;
    }
  }
}

…anyone in the world with your project ID can read every document in every collection. Test-mode rules ship with this exact pattern; they're meant to be temporary.

The classic mistakes I see again and again

After running this scan + reading hundreds of firestore.rules files in the wild:

1. Test-mode never replaced

match /{document=**} {
  allow read, write: if request.time < timestamp.date(2099, 1, 1);
}

Someone wanted "test mode but not 30 days," changed the date to 2099, forgot about it. Three years later, still wide open.

2. Auth-only without ownership

match /users/{uid} {
  allow read, write: if request.auth != null;
}

This means any logged-in user can read or write any other user's document. Sign up with a throwaway account → read everyone's data.

3. Read-open, write-protected

match /products/{id} {
  allow read: if true;
  allow write: if request.auth.token.admin == true;
}

Innocent for product catalogs, fatal for /payments or /users.

4. Wildcard match with no terminator

match /tenants/{tid}/{document=**} {
  allow read, write: if request.auth.token.tenant_id == tid;
}

Looks fine. But if the token is forged or tenant_id claim is missing, the rule grants access. Most apps don't validate the claim is present.

How to scan your own project

I built a free in-browser scanner at perufitlife.github.io/firebase-security-skill/scan.html — paste your project ID, watch it probe a list of common collection names. The scan runs in your browser; nothing is sent to my server.

If you'd rather scan from the CLI:

npx firebase-security ./firestore.rules --project-id YOUR_ID

…or from Apify (no install): apify.com/renzomacar/firebase-security-auditor

Source code is MIT: github.com/Perufitlife/firebase-security-skill

A note on disclosure

I'm not naming any of the 8 projects here. The aggregate stat is the point — the same scan against any random sample of public Firebase configs will produce a similar leak rate. If you'd like me to re-run with names privately so you can verify against your own (or check if you're in the original sample), email me: renzomacar@gmail.com.

What "fixing it" looks like

For most leaks, the change is one block. Replace if true with the appropriate auth + ownership check for your data model. Example for a /users/{uid} collection where each user owns their own doc:

match /users/{uid} {
  allow read: if request.auth != null && request.auth.uid == uid;
  allow write: if request.auth != null && request.auth.uid == uid;
}

The auditor I built generates one of these snippets per finding, paste-ready.

If you find leaks in your project and want a written audit report (PDF) with all the snippets bundled + 30 days of follow-up Q&A, I do a $29 lite tier (top 3 fixes) and a $99 full audit (every match block, 24h delivery): perufitlife.github.io/firebase-security-skill

But please run the free scan first. Most projects find their own leaks in the report.