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.

If you’re open to smaller teams, I’d take a look at DigiHelp. We’ve done Webflow projects, internal tools, automation and startup websites. Usually easier to work with than larger agencies because you’re talking directly to the people building it. digihelp.si

Hey! Quick reality check on that premise first — I’d be careful with the “LinkedIn is replacing email” framing. It’s not really either/or, and the people getting the best results aren’t picking a winner, they’re running both together. LinkedIn is great for warming someone up and getting on their radar; email is still where the actual booked-call conversion tends to happen. The magic is in the combination, not the swap. A few things that have worked well for me: The single biggest one — automation should be your delivery mechanism, not your personalization. The moment LinkedIn becomes spray-and-pray, your reply rate tanks and you risk getting the profile restricted (and unlike email domains, you can’t just spin up a new LinkedIn account, so it’s a real cost). So the play is: automate the sequence, but build it off a genuine signal — a recent post, a funding round, a role change. One good trigger beats ten “I see you’re the CEO of {company}” openers. On the actual flow, what works is not pitching in the connection request. Connect with no note (or a really light one), then warm them up — like or comment on a recent post first so you’re a familiar name — and only then move into a short, conversational message. No formal email tone, one clear ask, lead with why you’re relevant rather than what you sell. Voice messages are genuinely underrated and a great differentiator, but they land best a little later in the sequence once there’s a sliver of familiarity — not as the opener. Keep them under ~30 seconds and reference something specific to them in the first line, otherwise it reads as a template with extra steps. On assets — resist dropping a deck or a gated PDF cold. A lightweight, relevant resource or a short Loom converts way better than “here’s our one-pager.” Tool-wise, anything multichannel that lets you blend LinkedIn + email in one sequence (HeyReach, Lemlist, La Growth Machine and similar) is the right category — but honestly the tool matters less than the signal + restraint. And keep your daily connection volume conservative, especially without Sales Nav, or you’ll get throttled. Happy to share the sequence structure I use if that’d be helpful!