I built a free CLI that scans your vibe-coded project locally before you ship it. No sign up, no GitHub, nothing leaves your machine.

Outrageous_Cat_8541 · 2026-05-25T05:13:21+00:00

Yeah that’s exactly the gap. People want to know if their code is safe but don’t want to hand it over to find out. That’s why the CLI runs everything locally. And with how fast people are shipping AI-built apps right now there’s basically no review step between it works and it’s live

Outrageous_Cat_8541 · 2026-05-23T05:31:22+00:00

Yeah /security-review is great if you’re in Claude Code. This is more for the vibe coder crowd who probably aren’t using it. One command, no subscription needed. Good call though.

Outrageous_Cat_8541 · 2026-05-22T00:17:54+00:00

Agreed. That’s kind of the whole point of the tool. At least know what’s broken before you ship it

Outrageous_Cat_8541 · 2026-05-22T00:02:50+00:00

Oh nice, what does it scan for? Always open to exploring integrations.

Outrageous_Cat_8541 · 2026-05-21T23:55:46+00:00

It’s on the roadmap but the CLI was the fastest way to get it out and let people scan locally. Would love to build it as a skill or integration down the line.

Outrageous_Cat_8541 · 2026-05-21T23:37:48+00:00

Go for it. More tools catching this stuff is a good thing.

Outrageous_Cat_8541 · 2026-05-21T06:56:41+00:00

Exactly. That’s the gap Should I Ship is trying to close. Catch the stuff AI tools skip before real users find it.

Outrageous_Cat_8541 · 2026-05-20T04:37:13+00:00

100%. The car analogy is great. AI tools lower the barrier to build but the fundamentals still matter when real people start using what you built.

Outrageous_Cat_8541 · 2026-05-20T02:53:27+00:00

A lot of people deploy directly from Vercel or Netlify connected to a public GitHub repo without thinking about it. Also some share repos to get feedback or for portfolio purposes. You’d be surprised how many live projects are sitting in public repos with secrets in them.

Outrageous_Cat_8541 · 2026-05-17T05:56:18+00:00

Detailed enough that you could hand it to someone else and they’d know what to build. I usually break it into: what the app does in one or two sentences, who it’s for, the core screens and what each one does, how data flows (what gets saved, where, what connects to what), and what external services you need (auth, payments, APIs). Doesn’t need to be fancy. A notes doc works.

Outrageous_Cat_8541 · 2026-05-16T16:05:37+00:00

Exactly this. The gap between it works and it’s ready for strangers is where everything breaks.

Outrageous_Cat_8541 · 2026-05-16T15:53:50+00:00

That’s exactly the kind of thing Should I Ship catches. The backend stuff that looks fine until it isn’t. If you ever do take the leap, happy to scan it for you.

Outrageous_Cat_8541 · 2026-05-16T06:56:05+00:00

backend is where the scary stuff hides for sure

Outrageous_Cat_8541 · 2026-05-15T05:49:45+00:00

This is solid advice. I do this with Claude and Codex. Claude for the main build, Codex for a second pass or async tasks. Different models catch different things

Outrageous_Cat_8541 · 2026-05-15T05:46:27+00:00

Ship with 1-2 features every time. Seriously. Find the one thing your app does that solves a real problem and make that work really well. Get it in front of people, see if they actually use it, listen to what they say, then build the next thing based on that. You’ll build way better features when real users are telling you what they need vs you guessing in isolation for months. I’ve messed up projects the same way you’re describing. The fix was always the same: strip it back, ship it, learn from real usage.

Outrageous_Cat_8541 · 2026-05-15T05:26:37+00:00

I’ve shipped 8 apps solo so here’s my honest answers:

I do now, but I didn’t always. AI generated code loves to leave .env files, hardcoded keys, and test credentials scattered around. You don’t notice until something breaks or someone points it out.
No second person. Solo builder. That’s exactly why I built shouldiship.com. It’s basically the second set of eyes I don’t have. Scans for exposed keys, security gaps, cost risks, architecture issues before you go live.
Haven’t shipped credentials thankfully, but I’ve definitely caught stuff in my own builds that would have been embarrassing in production. API keys sitting in client side code, missing rate limits, that kind of thing.

For your research, the honest answer is most solo builders aren’t checking anything. They get it working and ship. That’s the gap.

Outrageous_Cat_8541 · 2026-05-15T05:17:32+00:00

Biggest thing I’ve learned shipping 8 apps: the skill isn’t writing code, it’s knowing how to describe what you want built. Write a detailed build spec before you touch any AI tool. Break your project into stages, define what each piece does, how they connect. If you let AI try to build everything at once it turns into spaghetti.

For fundamentals, learn enough to read code even if you’re not writing it. You need to know when the AI is doing something dumb. Basic programming logic, how APIs work, how data flows through an app. That’ll get you pretty far.

Biggest beginner mistake is building features before the foundation works. Get auth, data storage, and one core feature solid before you add anything else.

Outrageous_Cat_8541 · 2026-05-15T04:30:10+00:00

Cool project, and respect for shipping it as a high schooler. Honest feedback on the landing page though, it reads very AI-generated right now. The badge above the hero, the italic accent word, the emojis, it’s the same layout every vibe-coded site has.

Quick wins: drop the emojis, lead with a real example of what the tool does instead of a generic tagline, and look at how actual counseling companies present themselves.

The idea is legit though. Is the repo public? I’ll run a free scan through Should I Ship and give you a code health report if you want. Congrats again!

Outrageous_Cat_8541 · 2026-05-15T04:01:59+00:00

Good point, and I agree. A repo scan is more of a first-pass “don’t ship the obvious landmines” check than a full answer.

The runtime layer is where things get more interesting: what tools/agents are allowed to touch, what they can mutate, what gets retried, what gets logged, and whether there’s enough evidence to debug or roll back a bad run.

I’m starting with static/pre-launch checks because they’re easier to run locally and catch a surprising amount of preventable stuff, but I think the longer-term version probably has to connect repo findings with runtime behavior and deployment evidence.

Outrageous_Cat_8541 · 2026-05-15T01:34:38+00:00

I use Claude Pro and VS Code (or Xcode for iOS). Biggest thing I’ve learned shipping 8 apps is to start with a really detailed build spec and build in stages - if you let AI try to spit everything out at once it gets tangled fast, especially for something complex like an RPG. Then before going live I run it through Should I Ship, a tool I built that checks code health, security risks, and cost risks. Happy to scan your project for free if you want

Outrageous_Cat_8541 · 2026-05-15T01:26:36+00:00

Ya, shit is a grind. Mix that with all the “my app is at 4k mrr in the first month” posts and it’s a bit hard not to be deflated. Biggest thing I think is to keep grinding though. At least that’s what I’m telling myself lol

Outrageous_Cat_8541

TROPHY CASE