VibeCodeList

If you're fixing the last bugs before launch, we're building a place to launch it. Waitlist: vibecodelist.com

Signs AI is patching a symptom, not the bug: 1. The third fix touches the same lines 2. Works on your screen, breaks on your phone 3. Each fix adds a check, none removes a cause Two of these, stop. Write down what's true about the system, then have the model rebuild that part.

The break we see most often isn't taste, it's the boring part. A build can run for days and still never decide which rules the data has to keep, so it looks finished right up until a second thing writes to the same table.

Yep, which is why the rule belongs in the database, not the API. A check constraint or one update function every writer has to go through, so a cron job can't quietly write paid plus pending at 3am.

Ex-CTO into GTM is the hard direction. Code tells you exactly when it's broken. An audience just goes quiet, so you end up learning to read silence.

Check the database before the UI. If the row can hold paid=true and status='pending' at once, no frontend fix saves you. One status column with allowed transitions kills most of these.

The build got cheap. Finding out whether anyone wants it didn't, so that first real user conversation is now the expensive part.

The interesting test is the file both agents need, like package.json or the main scene. Backing off works right up until neither one can finish without touching it.

If you're building from a real complaint, we're building a place to launch it. Waitlist: vibecodelist.com

Counting people instead of mentions is the step most roadmaps skip. One user asking four times feels exactly like demand until you put names next to it. The competitor-reviews check is a good tiebreaker: if their users complain too, you're not imagining it.

Three signals an idea is worth building, from weakest to strongest: 1. Strangers say they'd use it (costs them nothing) 2. Someone complains about the problem without being asked 3. That same person tries your rough version the day you send it Most people stop at 1. Build for 3.

Disable submit after the first click so three of those requests never leave the browser. Key the webhook too: Stripe retries payment_intent.succeeded, and you can still grant the plan four times.

Most replies in this thread are tools for other founders. Sunday on X is founders selling to founders. The people building for plumbers and dentists are probably offline, which is exactly why they're worth finding.

We're building a place to list what you shipped with AI. Waitlist is open: vibecodelist.com

Three things a free clone can't copy quickly: 1. How fast you answer support 2. The boring feature that never breaks 3. Knowing which users stick around past month one If your launch post is about the feature, it's about the part they can copy. Write it about these three.

A tiny Mac app hitting $1k is the cleanest version of the game: one job, obvious from the screenshot, no onboarding. Clones tend to show up around now, so how fast you answer the first support emails is what protects the next $1k.

Creative direction before the first prompt is the step most vibe sessions skip. That's usually why three hours actually lands in prod.

Worktree details grouped by date is usually what disappears into a terminal tab. Fuzzy search across a dozen branches is how you stop shipping to the wrong one.

The fun ends the first time you have to explain a table the agent invented and you never named. Two hundred users just makes that bill arrive faster.

The "specific ICP" part is carrying the whole idea. Generic auto-outreach already exists and mostly gets ignored. One that only knows, say, independent gyms can write a first line someone actually answers.