SaaStr Vibe-Coded Its Own Calendly in 20 Minutes — and Their AI Agent Was the One Who Decided To Build It
EntrepreneurshipSaaStr was paying for Calendly. It worked fine. No outages, no complaints, no compelling reason to replace it.
Their AI agent, 10K, recommended building a replacement anyway. The reason was specific: Calendly could be integrated via API to do most of what they needed, but the routing logic — directing each incoming company to the right team member based on existing account ownership in Salesforce — required proprietary data that Calendly could never access directly. 10K built it on Replit in approximately 20 minutes.
The News
The custom scheduling tool sits at the end of SaaStr’s sponsor sales funnel and does four things Calendly doesn’t:
Intelligent routing. When a company books, the system checks existing Salesforce account ownership and routes to the team member who already has that relationship. When Base44 came in, it went to the team member managing Replit and Lovable relationships — because that’s where the existing context lives.
Dynamic prospectus generation. Before the meeting, the system builds a personalized page displaying the prospect company’s name, competitor attendance data from prior events, and the agent’s recommended sponsorship package. The meeting starts with the prospect already knowing what’s relevant to them.
Engagement tracking. If a prospect starts the booking flow and abandons, the system alerts the team for proactive follow-up. Calendly sends a booking confirmation; this sends an abandonment signal.
Data integration. Everything connects back to Salesforce and the custom company profiles. The booking isn’t just a calendar event — it’s a step in a tracked workflow.
The Framework
Jason Lemkin’s build vs. buy decision came down to four questions, which he now applies to any potential custom build:
- What does this accomplish that vendors cannot?
- Would API integration resolve most of the functionality?
- What proprietary data does it require?
- What’s the development timeline, and what’s the fallback plan?
For the Calendly replacement, questions 1 and 3 did the work: the routing logic required Salesforce data, the development timeline was 20 minutes on Replit, and the fallback was Calendly itself.
The “buy by default” principle held — if Calendly could have been API-integrated to achieve the same routing, they would have kept it. The custom build only happened because the specific capability they needed was unreachable through the existing tool.
The So What
The interesting implication isn’t that you should replace your SaaS tools. It’s that the build vs. buy decision now has a different cost structure than it did two years ago.
A 20-minute Replit build on a weekday afternoon has a different risk profile than a two-week engineering sprint. When the marginal cost of a custom build drops below a certain threshold, the “just use the existing tool” default becomes worth questioning more often — not for every tool, but specifically for the ones where your proprietary data would enable capabilities the vendor can’t reach.
The four-question framework is the useful output: it’s not a manifesto for replacing SaaS, it’s a filter for identifying the narrow set of cases where building is actually the better answer. Most of the time, the existing tool wins on questions 2 and 4. The cases where it doesn’t are the ones worth acting on.
SaaStr’s Calendly replacement is a good example precisely because the original Calendly was working fine. The replacement happened because of what the vendor couldn’t do, not because of what it was doing wrong.
Source: SaaStr
Content created with AI assistance and reviewed for accuracy.
Join the conversation
Stack Insiders is our free community for readers who want to go deeper — share resources, ask questions, and connect with others across every vertical we cover.
Join Stack Insiders →