After launching b4uship — a security scanner for vibe coders — I did what every solo builder does when the core product works: I started building more features.
Over a weekend, I shipped three ambitious additions:
- Auto-fix PRs — One click to generate a GitHub Pull Request that fixes the vulnerability
- A Firefox browser extension — Scan any page instantly from your toolbar
- Guardian subscription — $29/month for auto-scan on every git push, Slack alerts, and trend tracking
They were technically impressive. They demonstrated real engineering skill. And exactly zero people used any of them.
This is the autopsy.
Feature #1: Auto-Fix PRs (176 Lines of Code, 0 PRs Created)
The idea was compelling: you scan your code, b4uship finds a vulnerability, and instead of manually fixing it, you click "Fix It" and a Pull Request appears in your repo with the secure version.
Here's what the backend does:
- Connects to GitHub API with the user's OAuth token
- Gets the default branch and latest commit SHA
- Creates a new branch called
fix/b4uship-{random} - Fetches the vulnerable file's content
- Sends the file + vulnerability context to Google Gemini
- Gemini generates the fixed code
- Commits the fix to the new branch
- Opens a Pull Request with severity, CWE reference, and explanation
It works. The code is 176 lines, cleanly structured, properly error-handled. I tested it on my own repos. The PRs it generates are legitimate — correct branch, proper descriptions, actual code changes.
So I built the UI button. "1-Click Auto-Fix PRs" with a sparkle icon and a pulsing "Alpha" badge.
Then I looked at it and thought: would I actually click this?
Would I let an AI-powered tool automatically commit code to my repository based on a Gemini-generated fix that I haven't reviewed?
No. I wouldn't.
And if I — the person who built this tool — wouldn't trust it, why would anyone else?
What I Got Wrong
The feature solved the wrong problem. The hard part of fixing a security vulnerability isn't writing the fix — it's understanding the context. Why is this code structured this way? What would break if I change it? Does this fix introduce a new issue?
A one-click PR skips all of that context. It turns a judgment call into an automated action. For security fixes specifically, that's backwards. You want more human review, not less.
The feature is still in the codebase. The API route works. The UI shows "Coming Soon." I might enable it someday for low-severity findings like missing headers. But for anything involving auth, data handling, or business logic, auto-fix is the wrong abstraction.
Lesson: Don't automate decisions that require judgment. Automate the tedious parts — finding the issue, explaining it, generating a starting point — but leave the final action to the human.
Feature #2: Firefox Browser Extension (2 Manifest Files, 0 Installs)
I built a full browser extension. Two versions — one for Firefox (Manifest V2) and one for Chrome (Manifest V3).
The extension injects a content script on every page. Click the toolbar icon, and it runs a quick security scan: checks headers, SSL, cookies, exposed files. Results appear in a popup overlay.
It worked locally. I used it for a week during development.
Then I thought about distribution:
- Firefox Add-ons requires a review process (2-4 weeks)
- Chrome Web Store requires a $5 developer fee and review
- Both require screenshots, descriptions, privacy policies
- Updates need re-review
- Users need to trust a security extension with
<all_urls>permission — full access to every page they visit
The extension sitting in my repo and the extension being in someone's browser are separated by weeks of administrative work that has nothing to do with building software.
I never submitted it.
What I Got Wrong
I built the feature before validating the distribution channel. The extension was a technical exercise, not a user acquisition strategy. Nobody was asking for a browser extension. I built it because I could, not because anyone needed it.
The codebase has two full extension directories with manifests, content scripts, popup UIs, and icon sets. They work perfectly. They're completely useless.
Lesson: Before building a feature, map the full path to the user. If the distribution channel requires more work than the feature itself, that's a red flag.
Feature #3: Guardian Subscription — $29/month (0 Subscribers, $0 MRR)
This was the revenue play. The free tier shows your grade. The one-time $29 Launch Scan unlocks the full report. Guardian at $29/month was supposed to be the recurring revenue engine.
What Guardian promises:
- Everything in Launch Scan
- Auto-scan on every git push
- Slack and email alerts when new vulnerabilities appear
- Fix-it-for-me auto PRs (the feature from #1 that nobody uses)
- Grade trend tracking over time
It's a beautiful pricing card on the landing page. Clean design, gradient border, feature bullets with checkmarks. A "Coming Soon" button with disabled state.
Here's the problem: Guardian requires building four separate systems:
- GitHub webhook infrastructure — Listen for push events, trigger scans automatically
- Slack app — Register with Slack, handle OAuth, send notifications
- Recurring billing — Current Stripe setup is one-time payments. Subscriptions need a completely different flow with usage tracking, cancellation, proration
- Historical data — The database has 3 tables: users, scans, payments. Trend tracking needs a time-series data model
I priced a product I hadn't built. The pricing card was aspirational architecture — a roadmap disguised as a feature.
What I Got Wrong
Showing "Coming Soon" on a pricing page sets an expectation you haven't committed to. It's worse than not showing it at all, because now users are making decisions based on a feature that may never exist.
Should I have launched with just the free tier and $29 one-time scan? Probably. The pricing page would have been simpler, the expectations clearer, and the pressure to deliver Guardian wouldn't have existed.
Lesson: Don't put roadmap items on your pricing page. Ship what exists. Add tiers when they're real.
The Pattern
All three features share the same mistake: building what's interesting instead of what's needed.
- Auto-fix PRs: Technically impressive, solves a problem nobody has
- Browser extension: Works perfectly, impossible to distribute
- Guardian subscription: Beautiful pricing card, requires 4 new systems to deliver
Meanwhile, the features that actually get used are boring:
- Paste a URL, get a security grade → this is 80% of usage
- Paste code, see what's wrong → this is 19% of usage
- Everything else → 1%
The core scan takes about 15 seconds. Users land, scan, see their grade, and leave. Some pay $29 to unlock the full report. That's the product. Everything I built on top of it was engineering for engineering's sake.
What I'd Do Differently
Build less. The weekend I spent on these three features could have gone toward improving the core scan — better detection rules, fewer false positives, clearer explanations. That would have moved the needle on conversion. A browser extension never would.
Talk to users first. I had exactly one user (from a mentoring referral) when I built these features. I didn't ask what they wanted. I assumed. If I'd asked "what would make you pay $29?" the answer probably would have been "more accurate results" — not auto-fix PRs.
Ship the pricing page you can deliver today. Free tier + one-time unlock. That's it. No "Coming Soon." No aspirational tiers. When the $29 unlock is converting well enough to justify building a subscription, then add Guardian.
Current Status
- Auto-fix PR route: 176 lines, deployed, gated behind "Coming Soon" UI
- Browser extension: 2 manifest files, full content scripts, never submitted to any store
- Guardian tier: Pricing card rendered, button disabled, 0 infrastructure built
Total time invested: ~20 hours across a weekend.
Revenue generated: $0.
Users served: 0.
The core URL scan — the feature I built in 4 hours on Day 1 — is still doing all the work.
ContentsTailor is a micro venture studio. We build products, cut the features that don't work, and document both the wins and the waste. See all projects or apply to build with us.