Vibe Coding Day 12, Maybe the final thread here. I spent 100 hours building a commercial-grade app with vibe coding. Some observations from the experience. My top 13 learnings to help you -- vibe code your own one. A thread🧵

Note: I co-founded a pioneering SaaS that scaled to $200M ARR, so while I'm not an engineer and haven't really coded since high school (and that doesn't really count) -- I do have context on what commercial software requires. I love these apps. But if you are really going for it, know their limits. At least, their limits today. Things are changing so fast, these learnings will be out of date I am sure even in 90 days.

1/13: Start with a throwaway hack. Spend 60 minutes max telling a vibe coding app your wildest product dreams without any planning. See what emerges. But commit upfront to throwing it away—this isn't your real product, it's your education. That first hour will teach you more about platform capabilities and limitations than any tutorial.

2/13: Before writing any code, spend a full week studying 20 production apps built on vibe coding platforms. Not casual browsing—actually use apps that are live, taking payments, serving real customers. You're looking for what's genuinely possible at scale and where limitations bite hardest. This reconnaissance saves weeks of frustration later.

3/13: Define your production requirements before you start building. Ask: 1⃣How secure does this need to be? 2⃣Who will maintain it after launch? 3⃣Do you need it to scale to 100 users or 100,000? 4⃣Did you find another vibe-coded app in production, with paying customers, at your complexity level? If you don't have solid answers, stop building and start researching.

4/13: Write the most detailed specification you can manage. Map every page, workflow, permission level. Define email systems, dashboards, user management flows explicitly. Yes, this seems counterintuitive for natural language prompts, but it forces you to think through edge cases and becomes your north star when AI suggests unwanted features.

5/13: Some features look simple in demos but become engineering nightmares. Examples today at least (and this is constantly changing): ▶️ reliable email delivery ▶️OAuth/identity management ▶️media generation ▶️native mobile apps ▶️custom design beyond templates ▶️enterprise security. These consistently cause pain across platforms. Plan extra time or consider if they're actually necessary for MVP. Find a seasoned engineer that has built on your platform and ASK them. ASK them.

5/13: Some features look simple in demos but become really big engineering challenges. Examples today at least (and this is constantly changing): ▶️ reliable email delivery ▶️OAuth/identity management ▶️media generation ▶️native mobile apps ▶️custom design beyond templates ▶️enterprise security. These consistently cause pain across platforms. Plan extra time or consider if they're actually necessary for MVP. Don't assume your static demo that seems to do these thing well really does them well. Find a seasoned engineer that has built on your platform and ASK them. ASK them.

6/13: AI systems fabricate data when they fail. Everyone that has worked on ANY vibe coding platform, including Claude Code, knows this. It is a bug but also a feature. Without this, they can't solve problems. An AI on ANY platform when it hits roadblocks will generate fictional data. This isn't a bug—they're trained to provide output rather than admit failure. After multiple failed attempts, they'll create convincing fake data instead of saying "I can't do this." You need to understand this, accept it, and work around it. This will take time.

7/13: Spend your first full day learning every platform feature, not building. These platforms pack tremendous functionality into their interfaces. Every icon, menu option, feature exists for a reason. You can't leverage capabilities you don't know exist. This isn't optional research—it's essential knowledge for commercial-grade apps. There isn't a solution to every challenge. But the platforms have more solutions that you will think at first. And they are kind of nerdy. In a good way, but nerdy. Deep down they were built for developers, no matter what the marketing says. Accept that and get to know EVERY feature before you start. If you don't understand a feature, an icon, an acronym, then STOP. Go research it. Now. Not later.

8/13: Master rollback systems on day one, before you need them desperately. Most platforms offer elegant version control much like video game save points. Practice rolling back intentionally while stakes are low. Understand exactly how it works, what gets preserved, what gets lost. This becomes your most valuable debugging tool.

9/13: AI will make changes you didn't request. It just will. It'll modify settled features, add unwanted functionality, break working code while "improving" something else. Defense: Add "NO CHANGES WITHOUT ASKING" to every prompt. When discussing changes, state "NO CHANGES. NO CODE. JUST DISCUSSION." Reduces unwanted modifications ~80%. But it doesn't stop them. This is true of every platform. In the end, they all run on Claude -- mostly. They all have varying levels of the same issues from that. They will >all< make changes you didn't request. It's just the more prosumer apps will go further, since the developer-focused coding apps are more isolated in terms of the changes they make.

10/13: Learn to fork your application when it reaches stable complexity. Early on, rollbacks handle most issues. But as your app grows complex, you might not know which version to roll back to. Fork at stable states to create safe experimentation branches while preserving known-good versions. Think insurance policies.

11/13: Budget 150 hours across a full month to reach commercial quality. Maybe more. ▶️That 20-minute prototype is 5% of your actual work. ▶️More than half your time will be testing, debugging, refinement. The initial build is easy—making it reliable, secure, user-friendly requires the majority of effort. Don't let demo speed fool you.

12/13: Accept your new role as QA engineer. Once you're days into serious development, expect daily routine of: ▶️taking bug screenshots ▶️writing detailed reports for AI ▶️testing partial fixes ▶️retesting edge cases ▶️documenting new issues ▶️running unit tests on your fork This isn't a vibe coding limitation—it's software development reality. Platforms handle coding; QA remains human work. The platforms do do ... some. But only some. You can't rely on them to do your QA alone.

13/13: Plan your exit strategy from day one. Most commercial apps eventually outgrow prosumer vibe coding platforms due to scale, customization, or security needs. Options: 1⃣platform code export 2⃣hybrid approach 3⃣complete rebuild, or ... 4⃣staying and scaling. The truth is, on the prosumer apps today, most leave. Not all. But most that are building true commercial-gade apps. For now. This doesn't mean you have to. But have >options< when you start. Have ... an exit plan if you need it. Document business logic, maintain specs, evaluate regularly. If your app gets complex, in the end, you may find it easier to leave than work around accumulating constraints.

Vibe coding platforms are genuinely magical for certain types of applications—and genuinely insufficient for others. Your job is figuring out which category your project falls into before you're too deep to change course. These are powerful tools with specific constraints, not replacements for understanding what commercial software requires. They are tools. Not dev teams. Remind yourself of that every single day.

The platforms will keep evolving rapidly. What's impossible today might be straightforward in six months. But right now, think of "prosumer" vibe coding without touching code as just as likely a bridge to traditional development for commercial apps ... than an end state. Use it to validate your market, refine requirements, build initial revenue—then make informed decisions based on real constraints, not theoretical possibilities.

12 days of vibe coding feels like ... 12 weeks. The late nights debugging, the dopamine hits when something finally works, the frustration when it breaks again. It's been one of the most intense learning experiences I've had in years. For me, it's time to step back a bit and do more planning, more thinking. I've found some of my new favorite apps. But I've also learned even I need to learn it all much better. Hopefully this helps you.

Code: very excited we've inspired @dharmesh to buy and go big here!!

Coda: Super excited our journey has inspired @dharmesh to buy and kick off a whole community here!

@dharmesh Day 11 here: