The RevOps guide to vibe-coding GTM apps that last

What’s inside the guide

Your team can already build the app. Someone describes the job to an assistant one afternoon, spends the rest of the day correcting what it got wrong, and by the end of the week three other people are using it. Work that sat on an engineering backlog for two quarters now takes a day.

What fails afterward is rarely the build. It’s everything the build was standing on. A field gets renamed in the CRM and the app keeps running on blank data for three days. A credential turns out to belong to a person rather than the company. The one machine it runs on goes into a drawer for two weeks.

This guide follows a single inbound lead routing app from the afternoon it was built to the day somebody else could run it. Five chapters, ten questions to ask before your next build, and the four things that have to exist underneath a GTM app before anyone other than its author can depend on it.

How this guide helps

• Choose the app worth building first: Ten apps GTM teams are building for themselves, plotted by how many systems they touch and how hard a mistake is to fix. The corner most teams underestimate is the one that touches almost nothing.
• Write the spec that decides the build: A completed build spec for a real app, including the two answers that matter more than the rest: what happens on a duplicate, and what happens when a lookup comes back empty.
• Recognize the failure that makes no noise: Most GTM apps don’t fall over. They keep running and get quietly wrong, for days, until somebody in sales asks why a lead went to the wrong rep.
• Know what running actually requires: The four things an app has to do before it runs without you, and why a laptop does none of them.
• Hand it over without writing a document: A login, limits on what people can change, a name in the owner row, and a record of every run. Documentation isn’t one of the four.