AI broke your build? Search the fix.

GitClear data: ~45% of AI-generated code has at least one security issue. The fix isn't "stop using AI" — it's adding a security pass to every PR before merge. Read your dependencies, check for hardcoded secrets, run a free SAST scanner like Semgrep or GitHub's CodeQL once a week. The Moltbook breach (1.5M tokens leaked 3 days after launch) was a missing env var check a human would have caught in 30 seconds.

This is the universal vibe coding experience and it's not a skill issue. The first 80% is patterns the model has seen 10,000 times. The last 20% is your specific edge cases, error states, browser quirks, and integration glue — things no model has seen exactly. Plan for it. Block out 3x your gut estimate for the polish phase. If you keep promising "one more hour", you're estimating against the 80% phase.

GitClear measured 4x more duplication in AI-assisted codebases. The model doesn't know your existing helpers exist unless you point at them. Two habits: (1) Keep a `CLAUDE.md` or `AGENTS.md` listing utilities and where to find them. (2) After every feature, ask the agent: "Did this duplicate logic from anywhere? Show me the closest existing helper." Even imperfect dedup beats the default behavior.

If you can't navigate your code, you can't fix bugs and you can't add features without making it worse. Spend an afternoon writing an architecture overview into `ARCHITECTURE.md` — what each top-level folder does, where state lives, what's a server vs client boundary. Make the AI generate the first draft, then audit it yourself. The act of auditing is half the learning.

Two patterns to break: (1) Always ask "how would you verify this works?" before accepting code. Forces the model to think about test cases. (2) If something feels off, paste the code back and ask "what would happen if X was actually empty/null/large?". Confident-wrong code usually has a single edge case the model didn't model.

Means your tests cover the wrong layer. AI loves to write tests against the implementation it just wrote — tautological tests. Add one end-to-end smoke test per feature that uses the feature like a user would. Playwright or even a manual checklist beats 200 unit tests that all assert the implementation didn't change.

This is TypeScript working correctly — the cascade is showing you every place that needs to change. Don't suppress with `any` or `@ts-ignore`. Walk the errors top-down: fix the root type, regenerate, fix the next one. If you find yourself in a rabbit hole, the change was too big — git stash and split into smaller changes.

Constrain the model upfront. "Don't add new state, don't add new dependencies, don't add new files unless I explicitly ask." Write it once in your AGENTS.md and reference it. Without constraints, the model defaults to "add everything that might be useful" which is the opposite of what shipped code needs.

Training data is 6-12 months stale. For fast-moving libs (Next.js, React, Tailwind), paste the relevant docs section into context before asking for code. Tools like Context7 MCP do this automatically. Once a quarter, ask the model: "What's the current best practice for X in [library] version [Y]?" and verify against official docs.

The refactor instinct is escape, not strategy. Spend 45 minutes with the actual bug: add logging, bisect the change history (`git bisect`), reproduce in isolation. 9 times out of 10 the bug is a 3-line fix once you understand it. Refactoring while you don't understand the bug just moves it somewhere harder to find.

Real users, real installs, real opens. Where they come from: r/AndroidApps closed-testing weekly thread, indiehackers.com, Twitter, your existing email list. Aim for 30+ because Google sometimes pushes back below that. Stagger sign-ups so people don't all churn at once. Your iOS friends count if they actually have an Android device.

Open the rejection in Resolution Center and click "reply" not "resubmit". Ask for the specific guideline number (e.g., 4.0, 5.1.1) and the specific screen they're flagging. Reviewers respond to direct questions. Don't just resubmit hoping a different reviewer will pass it — same reviewer often picks it up again.

Cycle a fresh build every 60-75 days so you never hit the wall mid-testing. Internal testers (up to 100) don't count against this — only external testers do. If your build hits day 90 and you're not ready, upload any incremental change (version bump is fine) to refresh the clock.

90% of the time it's one of: (1) Missing env var in Vercel dashboard (compare with `vercel env pull`), (2) Node version mismatch — pin in `engines` field of package.json, (3) Edge runtime can't run a Node API you used, (4) File system writes that work locally don't on serverless. Check Vercel function logs first — they tell you which one.

Run `next build` and look at the route-level breakdown — it shows per-page kB. Then `npx @next/bundle-analyzer` for a visual. Usual culprits: a heavy lib imported in a layout (loads on every page), an icon set fully imported instead of tree-shaken, or accidentally bundling a server-only module into a client component.

Three gotchas: (1) `NEXT_PUBLIC_` prefix required for vars used in client code. (2) Vercel preview and production are separate scopes — set the var in both. (3) Server actions don't re-read env at runtime if hot-reloaded weirdly; redeploy clean. Always `vercel env pull` and check the .env.local matches what you expect.

Library update (often `eslint-plugin-react-hooks`) added a new rule. Don't suppress globally. Fix the violations — usually 5-10 lines — and the rule is doing you a favor by catching a real anti-pattern. If the rule is genuinely wrong for your code, disable it per-line with a comment explaining why.

Most ORMs (Prisma, Drizzle) run migrations on the dev machine but require a manual or build-step trigger in prod. Add `prisma migrate deploy` to your Vercel build command, or use Drizzle Kit's push in a postbuild script. Test by running it once manually against prod-like staging before relying on it.

Almost always DNS propagation — wait 1 hour, recheck. If still broken: (1) Verify the CNAME or A record matches Vercel/Netlify's exact target. (2) Remove and re-add the domain. (3) Check no other provider (Cloudflare proxy mode) is intercepting and serving its own (invalid) cert.

For Vercel: move heavy initialization out of the handler into module scope so it caches across warm invocations. For Supabase/Postgres: use a connection pooler (PgBouncer) — direct connections cold-start slow. For function size: trim deps, the larger the function the slower the cold start.

Both numbers are too small to draw conclusions. Get to 500 monthly visitors first — that's the floor where conversion data means anything. Until then, optimize for one thing: more eyeballs. Conversion optimization on 60 visitors is theater.

You haven't done real SEO yet — you've just claimed your name. Pick 3 long-tail keywords your audience actually searches (use Google's search-suggest as free research). Write one in-depth article per keyword, 1500+ words, with real examples. Three articles, three months of indexing — that's the actual start of SEO.

Subreddit rules vary but the universal pattern: post 5-10 useful, non-promotional comments BEFORE you ever post your link. Build karma in the sub first. When you do post, the format matters more than the content: "I built X to solve Y" works, "Check out my new app" doesn't. r/SideProject and r/IndieDev are more tolerant; r/programming is brutal.

PH is now a closed game — 80% of upvotes come in the first 4 hours from people you DM directly. Without a pre-built list of 50+ people who will vote, you'll stall. If you don't have that list, skip PH. Show HN, Reddit r/SideProject, and Twitter via build-in-public are more honest channels for small audiences.

Post Tue-Thu, 8-10 AM Eastern. Title matters more than content: leads with what you built and what's interesting about it, not your name. "Show HN: I built X — what surprised me about Y" outperforms "Show HN: My new app launched". Reply to every comment in the first 6 hours; engagement keeps you on the front page.

3% impression → page-view rate means your icon or subtitle isn't selling the click. Average is 5-7%. Test one of: (1) icon redesign with one strong visual element, (2) subtitle that says what the app does in 5 words, (3) screenshot 1 with a hook overlay. Change one thing, run for 2 weeks, measure.

ASO is keywords (visibility) + screenshots (conversion). You optimized half. Your impressions probably grew but nobody installs because the listing doesn't sell. Screenshot 1 + 2 carry 80% of the conversion decision. Test rewriting screenshot 1 with a clear value-prop overlay, ship it for 2 weeks, compare against baseline.

Zero reviews = no install. 5 reviews = install permission. 30 reviews = competitive. The jump from 3 to 30 is the highest-ROI marketing move you have. DM your first 30 users individually asking for a review. Not a broadcast — individual messages with their name. Conversion rate is roughly 30-40% if you ask right.

Following count means almost nothing now; consistency + engagement does. Reply to 10 accounts in your niche every day for 30 days. Don't quote-tweet for clout — reply with something useful. After 30 days your impressions on your own posts will 10-20x because the algorithm has learned you're active.

If a user reads only the first screenshot and can't say what the app does in one sentence, you have a conversion bug — not a marketing bug. Format that works: big overlay text describing the value ("Track your training, no spreadsheet needed"), small phone mockup behind it. Most apps make the phone the hero. The text is the hero.

Instagram is a brand channel, not an install channel — for indie apps. You can drive awareness, you can't drive installs reliably without paid promotion. If your goal is installs, redirect that time to Reddit, Show HN, or App Store SEO. Keep Instagram if it's joy; kill it if it's hope.

Price is a signal. $5 SaaS reads as "hobby project, will disappear". $19-29 reads as "actual product". For B2B tools, $49 minimum. Test by 3-4x your current price for new signups; existing customers grandfather in. If conversion stays flat, you were leaving money on the table. If it tanks, ratchet down — but most indie devs are too low, not too high.

0.3% is industry-typical for freemium SaaS. The fix isn't "shrink the free tier" — most users on free aren't going to pay no matter what. The fix is targeting paid users from the start with a trial (7-14 days, full features), not freemium. Trial converts 10-30%, freemium converts 1-5%.

Three legal options: (1) Stay in IAP — simplest, pay the tax. (2) Subscriptions get 15% after year 1 if you stay on IAP. (3) For digital subscriptions outside the app (link from your website), you keep 100% — Apple's recent ruling allows linking out. SaaS-shaped apps usually have customers sign up via web, then use the app.

Common pattern: annual = 10x monthly (16% discount). Anything more aggressive than that and you're discounting cash you can use. Anything less and customers feel punished for committing. Don't overthink it — pick 10x, observe for 90 days, adjust if needed. Mostly it doesn't matter as much as you think.

Coupon hunters are not your buyers — they're a separate audience that costs you LTV. If you must discount, restrict to: (1) Annual upgrades from monthly (rewards commitment), (2) Specific verticals where price is genuinely a blocker (students, nonprofits). Avoid generic 30%-off campaigns — they pull in the worst cohort.

Almost always one of: (1) Onboarding didn't show the value in 60 seconds, they got lost and gave up. (2) Pricing tier was confusing — they picked wrong and feel ripped off. Watch the first 5 refund recordings (Hotjar, PostHog). The pattern is usually the same screen. Fix that one screen and refund rate drops 50%+.

Twitter's selection bias is brutal — you see people's wins, not their abandoned projects. 99% of indies haven't shipped one thing in 6 months. You shipping 3 isn't behind, it's top 1%. Unfollow accounts that make you feel worse, follow ones that make you feel saner. Your real comparison is your past self.

The accounts you see are filtered by engagement. Engagement comes from extreme outcomes (huge wins, huge fails) — never the median. Median indie outcome: 6 months of work, $200/mo revenue, slowly dying. You don't see that. Cap your Twitter time at 15 min/day or you'll burn out comparing your inside to other people's outside.

Universal indie pattern. Two questions to ask before starting: (1) Is the new project actually different, or am I escaping a hard moment on the current one? (2) Will I be embarrassed in 6 months if neither is shipped? If both answers are uncomfortable, force-finish the current one — even badly. Shipping a small version of project N beats half-building N+1.

$100/mo at 20 evening-hours/week is $1.25/hour. The math doesn't justify the hours unless you're learning skills you couldn't elsewhere or the path to $1k/mo is clear within 90 days. Otherwise: either commit a quarter to push it to $1k+, or sunset it. Indie purgatory drains the energy you need for the next project.

You don't have a product problem, you have a fear-of-launching problem. Stacks don't fail products — products fail because nobody knew about them. Pick the stack you have right now, ship to production with that, get 10 paying users, then decide if the stack matters. Spoiler: at that point you'll never want to migrate.

Universal trap. Building is deterministic — your prompt either works or doesn't, you get an instant signal. Selling is probabilistic, delayed, often rejected. Solo founders need to schedule the unloved work like dental cleaning: 1 hour every morning before you let yourself open the editor. Not after — before. Otherwise it never happens.

Check metrics on a schedule, not on impulse. Weekly Friday 30-min review. Outside that window, don't open the dashboard. The data didn't change in 4 hours, but your stress level did. The anxiety isn't pointing at a real problem you can fix today; it's pointing at scarcity of progress signals which is just the nature of pre-PMF.

Without user contact you're drifting. 2026's data: solo founders who do 1 user call per week are 3x more likely to find PMF. "Call" can be a 10-min Discord DM. The hard part isn't time, it's the discomfort. Pick the friendliest user, ask one question: "What were you doing right before you opened the app today?" — listen for what you didn't anticipate.

Eric Ries's MVP: smallest thing that lets you LEARN whether the hypothesis is true. Not smallest thing that's shippable, not your minimum-acceptable-quality v1. If you're polishing features instead of putting it in front of users, you're past MVP and into v1 territory. That's not wrong, but call it what it is — and don't claim you're "validating" anymore.