Eva M.

Amazing - let me know how it lands with them 👌

Honestly love this. The version-control hell of "deck_final_v3_REALLYfinal.pdf" dies the moment everything lives at one URL - single source of truth, always current, way faster to iterate. And this is where it gets genuinely better than docs, not just equivalent: you can drop smart search right in. Full-text or even semantic/ask-a-question search across everything you've ever sent the client. A PDF graveyard is unsearchable; a living site where they can type "what did we agree on pricing" and land on the exact line - that's a real upgrade. Honestly one of the strongest reasons to go this route. Stuff I'd still think through before going all-in: • Portability - some people want to download, print, or forward. Worth a clean "print to PDF" path so you're not fighting that instinct. • Stakeholders who expect a "document" - legal, procurement, execs forwarding upward. A link can read as less formal/archivable to them. • Hosting + link rot - where it lives, who can access it, what happens in 18 months if the link dies. • Sign-off + archiving - anything needing approval or a frozen "agreed on this date" record should be snapshotted, not left as a living page. • Search caveat - it shines once there's real volume, and bad search is worse than none. If it's AI-powered, scope it tightly to your content so it doesn't start guessing. Net: HTML by default, smart search as the killer feature, export when the situation demands it. How's the client reacting so far?

Lend them small project to do. It can be small, you can easily figure out how they think and if they can use the tools :)

I think we’re actually pretty aligned. My point wasn’t that planning, architecture, or documentation don’t matter. Quite the opposite. The most successful AI-built products I’ve seen had very clear specs, constraints, and ownership from day one. Where I disagree with a lot of anti-vibe-coding takes is that they often assume the problem is AI itself, when in reality the problem is usually a lack of engineering discipline. If someone can create a mess with Claude, they’ll create a mess with a team of developers too. For a Series B+ company with an established product and existing customers, I’d absolutely be more cautious. The cost of mistakes is much higher and technical debt compounds across teams. But for startups still searching for product-market fit, I’ve found that the risk of moving too slowly is often greater than the risk of accumulating some technical debt. You can refactor code. It’s much harder to recover the time spent building something nobody wants. So for me it’s less “vibe coding vs traditional development” and more “appropriate level of rigor for the stage of the company.”

Sharing the sequence structure. Hope it helps :)

Andrew S. Respectfully disagree. I’ve built and shipped 10+ products that were largely vibe-coded, and the key factor wasn’t the coding style—it was having clear requirements, good architecture decisions, and ongoing iteration. Technical debt isn’t unique to AI-generated code. I’ve seen plenty of traditionally developed products accumulate just as much debt. The difference is that vibe coding lets you validate ideas and reach product-market fit significantly faster. For many startups, speed of learning is actually more valuable than spending months engineering the “perfect” solution upfront. If the product gains traction, you can always refactor. If it doesn’t, you’ve saved months of development time. AI is a tool. Bad engineers create technical debt with or without AI, and good engineers know how to manage it either way.