Twenty Minutes Is Not a Reason to Build

An agent offered to build SaaStr a replacement for Calendly, and built it in about 20 minutes. Jason Lemkin wrote it up on October 3, and the build was a good call. One sentence in the post is the one I would take out before a team copies it.

The short version

Jason Lemkin reports that SaaStr's agent proposed replacing Calendly, built a booker on Replit in about 20 minutes, and was right: the booker routes sponsor prospects and delivers a custom prospectus using data no scheduling vendor has. SaaStr makes the agent answer four questions before any build. The line to retire is his bar: at 20 minutes it was low, and at two weeks they would have kept Calendly. Build time no longer carries information, because every agent build is minutes. I said yes at that price 39 times in 80 days, and 13 of those agents ended with zero references anywhere else in the system. Keep the four questions. Replace the build-time bar with three lines: a named person who notices when it breaks, the existing workflow it joins, and a date to switch it off for a week.

What Lemkin published

SaaStr runs with three humans and more than 20 agents. 10K is the one that handles marketing and, more and more, revenue. While rebuilding the inbound sponsor flow with Amelia, 10K suggested dropping Calendly and offered to build the replacement itself.

Lemkin is careful here. An agent wanting to build something is a bad reason to build it, he writes, because agents like to build and following every suggestion would leave a three-person team maintaining a dozen homegrown tools. So they asked 10K to justify it.

The justification was data. When a sponsor prospect books, the booker hands them a custom prospectus (their company, their competitors who attended, the packages recommended for them) and routes the meeting to whoever on the team already works with similar sponsors. If someone opens the booker and leaves, 10K tells Amelia and offers to draft the follow-up. Calendly cannot know who owns which accounts or what a prospect was reading.

They have four questions for any build an agent proposes:

1. What does this do that the vendor cannot?
2. Would an API integration cover most of it?
3. What data does it need that only we have?
4. How long will it take, and what happens if it breaks?

They still buy almost everything. Salesforce, Clay, ZoomInfo, Gamma, and the rest are bought, and the advice to founders is to buy by default.

The sentence I would remove

"At 20 minutes of agent time, the bar was low. If 10K had estimated two weeks, we would have kept Calendly."

Lemkin gets to the right answer on this build, and he gets there through question three. The bar sentence is a different kind of claim. It says build time is what sets how hard you look at a proposal.

That worked when a build was two weeks. Two weeks was a real filter. Most ideas did not survive being asked to cost that much.

An agent removed the filter. The booker was 20 minutes. So is the next thing 10K proposes, and the one after. If the bar drops whenever the estimate is small, the bar is now on the floor for everything.

What I got for saying yes

I ran this experiment without meaning to. The write-up is 39 PM AI Agents Deployed: What Stuck, What Died, and Why.

Thirty-nine agents in 80 days. Eight in February, ten in March, twenty-two in April. Every one was cheap. None took two weeks. I approved each of them the way Lemkin describes, because the cost of trying was close to nothing.

Then I counted. Thirteen of the 39 had zero references from anywhere else in the system: no handbook chapter, no other post, no landing page, nothing that depended on them. Thirteen fired in the same 7 to 9 a.m. slot, and I read about four of those briefs with any care.

The clearest death was a tech-debt agent that ran every hour. It identified, ranked, and recommended fixes across a whole codebase. Engineers ignored it because it was tied to no sprint. PMs ignored it because it was tied to no commitment. It posted and posted, and the only reader was me, when I was procrastinating. My note on it at the time: the mistake was building the agent before the workflow.

It would have passed all four of Lemkin's questions on a generous day. No vendor did exactly that, an integration would not have covered it, it needed our code, and it was quick. It still should not have been built.

The running cost shows up in his next post

One day after the Calendly piece, Lemkin published what the cost looks like. On a Monday afternoon the model driving a build replaced ceoMatchingEmailService.ts, one of the two core engines of SaaStr Connect, with the five-byte text "DO IT." They restored it. Twenty-eight minutes later it happened again. Both times the model listed the empty file as a blocker it had found.

His conclusion is the honest one. Building this way is still far cheaper and faster for them than the old way, and part of every week goes to catching problems like Monday's. They plan the roadmap with that time already counted.

That is the price of a 20-minute build. You pay it later, in attention, every week the thing stays alive. I made a version of this argument about demos in Kill the 'I Built It in a Weekend' Flex: ask whether it was still running the weekend after.

The gate I would use

Keep the four questions. They are about whether the build is different enough to exist. Then add three lines about whether it will stay alive, and make a human write them:

5. Who is the named person who notices within hours when this breaks?
6. Which existing workflow does it slot into? One sentence.
7. On what date do we switch it off for a week and see who complains?

These are the survival traits from my own count, turned into a form. The agents that lasted had a named owner, a narrow scope, a workflow that existed before they did, and stable inputs. The seventh line is the kill-switch test from The Seven-Agent Reset: A Lean PM AI Fleet, One Agent Per Stage: no complaint after a silent week means retire or rebuild.

Run SaaStr's booker through it. A person gets told when a prospect bounces. It sits at the end of a sponsor funnel that already existed. Calendly is the fallback if it breaks. It passes, and it would have passed at two weeks too. That is my whole disagreement: the booker deserved to be built at either price, and my tech-debt agent deserved to be skipped at either price.

This one sits in Building a Company in Public because the evidence is my own wrong calls, published. I approved 39 because each was nearly free. The count of what stuck is the only reason I can tell you which question I skipped.

Pick one thing this week. Take the last tool an agent built for you, and write lines five, six, and seven for it. If you cannot fill in the name, you have your answer about the next one.

Related answer: Should you build an internal tool because an AI agent can build it in 20 minutes?

Sources: We Vibe Coded Our Own Calendly. Our AI Agent Pushed Us To Do It, and It Was Right., Jason Lemkin, SaaStr, October 3, 2026. Astra 6 Replaced a Core Engine of SaaStr Connect With Two Words, "DO IT," Twice in Under an Hour. Then It Said "I Did Not Make That Edit.", Jason Lemkin, SaaStr, October 4, 2026. 39 PM AI Agents Deployed: What Stuck, What Died, and Why, falkster.com, April 27, 2026.