How Cal.com Rebuilt AppSec After Going Closed Source

Matt Johansen sits down with Cal.com CEO Bailey Pumfleet to talk through the move to closed source and how Cal.com uses Gecko to secure every pull request.

Why Cal.com Went Closed Source

The decision came out of a shift in what it costs to attack software. Finding and exploiting a vulnerability once demanded a skilled researcher and a serious investment of time. But now, an AI model can scan public code and surface vulnerabilities almost instantly. As the largest open source Next.js project of its kind, Cal.com was facing AI-driven attacks on its code more or less daily, and being open began to feel “like handing attackers the blueprints to the vault”.

For a company holding calendars for startups raising rounds, banks moving large deals, and healthcare providers managing patient data, that risk wasn’t worth carrying. Cal.com went closed source to protect its customers, rewrote the critical systems around authentication and data handling, and shipped a community edition as Cal.diy. It reduced risk, but it left the harder problem untouched: closing a codebase does nothing to stop vulnerabilities from being written into it, and the team was shipping more code than ever. Pull request volume climbed from around 40 a day to 100 as they adopted AI coding tools, all handled by 25 engineers and two people on security.

More Scanners, Less Signal

The security Cal.com had in place lived alongside its engineering rather than inside it. Several scanners ran at once, legacy and AI native, some in the pull request and some running full dynamic tests, and each surfaced its own findings with its own severities, most of them false positives. The coverage they were meant to add arrived as duplicates and noise, and with the tools disagreeing on every change, nothing gave a reliable answer to the only question that mattered, whether a pull request was safe to ship.

“If you ask two different AI agents to review the same PR, they’re going to pull out very different results.”

Running more scanners did not add up to more security. It added more to reconcile, and that work fell to the two security engineers, who didn’t have the bandwidth to keep pace.

Making Gecko the Source of Truth

The value of consolidating on Gecko became apparent almost immediately. In place of the stack it replaced, Gecko became the single source of truth in Cal.com’s pull request pipeline, and what set it apart was context. Rather than flag patterns in isolation, it traced how data moved through the codebase and proved each finding with a working proof of concept. Drawing on the same production context the team had, it understood which issues were genuinely exploitable and which touched sensitive customer data. That let a small team cut straight to what mattered, ranking findings by real risk instead of raw severity, and it surfaced issues before they ever reached production, catching what the earlier tooling and manual pentests had missed.

“First instinct was, this is a nice product that easily bakes into an engineering process that cares about security and cares about quality.”

For a team of two security engineers, a tool they didn’t have to fight was the difference between a scanner and a program.

Security That Lives in the Pipeline

Finding a vulnerability never decided whether it got fixed, so Cal.com built its workflow around closing them. Every pull request runs through Gecko before it reaches a human reviewer. Gecko routes each finding to the developer who owns the code, with the context they need to resolve it, and custom rules strip out the noise while adding any missing context. Developer triage comments are stored in memory and used to shape future fixes, so each one lands closer to the codebase’s style than the last, and the system gets more aligned to how Cal.com works the longer it runs. Fixes happen inside the engineering process instead of getting handed off and forgotten, which is how issues get closed before anyone outside ever sees them.

“This is the new reality. Especially with Mythos, you’re always going to find new stuff.”

That feedback loop is what makes the whole thing predictable, and for Keith, who runs the pipeline day to day, predictability is the payoff. “Predictability is huge, and we can build a process so we get them fixed in the product as soon as possible,” he says, adding that “time to fix is the most important thing, and the number of criticals.” A tool that behaves the same way on every pull request is something a team can build around, and that is what moved security at Cal.com from an occasional activity into a continuous function.

Built Around How They Work

The relationship went beyond buying a tool. Cal.com tuned Gecko to its own codebase and fed back what a small team shipping at speed actually needs, and Gecko was built around that use rather than dropped on top of it. For a company with two security engineers and a hundred pull requests a day, that partnership is what turned a stack of findings into a security program.

Where This Leaves the Industry

Cal.com’s experience shows what the shift to AI-accelerated attacks asks of a modern team, and how the right partner turns that constraint into an advantage. Going closed source bought a one-time reduction in risk. Building continuous, context-aware security into the pipeline is what made the decision hold, and it let a 25-person team run at a coverage that would once have needed a department, without slowing its developers down.

AI changed the economics of software security enough to push a five-year open source company to close its code to protect its customers. Teams that get through it well will use that as a reason to rebuild how security work and Cal.com already has.

See what Cal.com sees. Try Gecko free on your own codebase, or book time with the founders at gecko.security.