He burned $4M to hit $100K ARR—but with 1 big change, he grew to $4.5M ARR in just 12 months. | Guy Podjarny, Founder of Snyk & Tessl

Guy Podjarny (00:00:00):
But still, our users were in the thousands, and then maybe they started broaching the tens of thousands. And what they weren’t doing is they weren’t paying. So when we launched that GitHub app, we also GA’d. I said, let the floodgates open, come pay us. It took us a moment to realize, they’re not going to pay. They’re just not. Two years and two months in, we were at $100,000 ARR. Not awesome. And we burned $4 million by that time. Four months later, we’re at $650K. A year later, we’re at $4.5 million. A year later, we’re at $119 million.

Pablo Srugo (00:00:28):
Wow!

Guy Podjarny (00:00:29):
And so the numbers really started escalating at that time. We raised $125 million in total. I would sort of point out, I don’t always encourage raising so much, but I say privately and I have to say publicly as well, I’ve got zero interest in building something small. We’re building big.

Previous Guests (00:00:45):
That’s product market fit. Product market fit. Product market fit. I called it the product market fit question. Product market fit. Product market fit. Product market fit. Product market fit. I mean, the name of the show is product market fit.

Pablo Srugo (00:00:57):
Do you think the product market fit show has product market fit? Because if you do, then there’s something you just have to do. You have to take out your phone. You have to leave the show five stars. It lets us reach more founders and it lets us get better guests. Thank you. Guy, welcome to the show, man.

Guy Podjarny (00:01:13):
Thanks for having me.

Pablo Srugo (00:01:14):
So now you’re working on a company called Tessl, which is kind of in the AI agent development space. But before that, you started a security company called Snyk that has grown tremendously. I think it’s doing over $300 million ARR today, which is huge. We’ll start there. Take us back to, I think it was 2014 or 2015 when you were starting it. What was the context? Maybe give us a little bit of your background and the origin story of it.

Guy Podjarny (00:01:37):
Sure, maybe you need some context for the background first. So I’m sort of a developer by trade, who turned to product, then eventually to entrepreneurship. At some point, I founded my first company when I was based in Ottawa. Small world, man. I founded Blaze with Mike, and within a couple of years, we sold it to Akamai. Blaze was in the DevOps space, focused on making websites faster, and ended up being on the forefront of DevOps and that first transformation, which was all about ops and performance.

Pablo Srugo (00:02:03):
And what year was this?

Guy Podjarny (00:02:04):
So this is 2010, founded Blaze.

Pablo Srugo (00:02:07):
So kind of with Verizon Cloud, AWS, all these sort of things.

Guy Podjarny (00:02:10):
Exactly. I was a part of the Velocity conference where many of the seminal DevOps talks happened and that whole wave took shape. So I was part of that first wave. In 2012, Akamai acquired us. Within a couple of years, I became the CTO of the web performance division at Akamai, which was about half of the company’s $700 million-a-year business. It was a fun ride—learning, staying there for about three and a half years, opening Akamai to the community, being involved in things like HTTP2 and, before that, SPDY, and thinking a lot about broadening and modernizing Akamai.

Pablo Srugo (00:02:44):
Why did you sell, by the way, like in early selling, that was just a really good kind of a rational buyer sort of thing, or just the opportunity within Akamai?

Guy Podjarny (00:02:50):
You know, you’re kind of using an example. So Blaze was like a web page compiler. It sat before the web page and made it faster by tweaking the CSS, the JavaScript, and the images on top of it. It needed to be in the line of fire, and we built a smart architecture that allowed us to put a lightweight component in that position with a brain behind the scenes doing asynchronous computation. That worked well from an interest standpoint and felt right, but it seemed that the right home for this technology would be a place already in the line of fire. We had a lot of partnership engagement with CDNs and ADCs—application delivery controllers like load balancers—and content delivery networks such as Akamai. It felt natural, as this was how many of the early users and customers wanted to build. It offered them a way to innovate or differentiate when everything was focused on network-level acceleration, while we provided application-layer acceleration, which was very compelling. From a long-term perspective, we either had to compete with the CDNs and ADCs or get acquired. We were in a good place with multiple potential suitors, and it felt like the right home. In the grand scheme of things—especially compared to Snyk—it was a small acquisition, but it gave me financial independence and the freedom to aim higher. We had a few paying customers, were in market, and even had a big publicity moment when we published a mobile performance report showing Android beating iPhone, which made us a top headline in tech news for three days straight—and Apple even responded. That was a wild ride. But I don’t know that we independently achieved product market fit. It’s not that we missed it or wouldn’t have gotten there—it’s just that we were acquired before we really reached it.

Pablo Srugo (00:04:37):
It was early right. 

Guy Podjarny (00:04:38):
But inside Akamai, it worked very well and immediately started selling. We learned a lot as we broke it apart within Akamai. It began as the full Blaze offering and more, all bundled into one premium product. Over time, though, it evolved into separate units of acceleration rather than one magical, all-encompassing solution. There were a lot of learnings through that process. I think it was the right move at the time, but what it did was put me in a global role within Akamai. I moved to London for several reasons and eventually got the itch to start another company.

Pablo Srugo (00:05:07):
How long did you stay at Akamai?

Guy Podjarny (00:05:09):
I spent three and a half years at Akamai. I learned a ton.

Pablo Srugo (00:05:13):
Did you know you wanted to go back into it or just kind of seeing things as they go?

Guy Podjarny (00:05:17):
Not really. Until I got close to the three-year mark, I was learning a lot, growing a lot, well paid, and felt like I was making an impact. But the main driver for leaving was that, to have a bigger impact at Akamai and work on what really mattered to me, I would have needed to move to Cambridge, Massachusetts, where Akamai was headquartered—and that wasn’t something I wanted to do. There was also a lot of cultural change and modernization happening. Akamai was a brilliant company with brilliant people, but it was very risk-averse, and I’m very risk-forward. I think I could have done something meaningful there, but not from afar. So my decision was to leave and start something new. My intent was actually to take a break. I had a long departure from Akamai—I resigned in March, my last day was July 1st, and by July 9th, I had incorporated Snyk.

Pablo Srugo (00:05:11):
Okay! 

Guy Podjarny (00:06:12):
It was not the next year, the same year, eight days later.

Pablo Srugo (00:06:15):
The idea was a year off to travel or a year off to figure out what to do? Was it more intentional?

Guy Podjarny (00:06:19):
The year off was more just an opportunity, and I was in a position to make that possible. As I wound down my time at Akamai, my mind started racing—thinking about what I wanted to build and exploring many different ideas. Eventually, the idea I settled on for Snyk was to conceptually bring DevOps to security. I had spent a decade in security before founding my first company, working in application and software security. We always wanted to reach developers but always failed. Watchfire was acquired by IBM Rational, which was IBM’s developer division. The acquisition succeeded financially by selling to auditors, but it didn’t succeed in breaking through to developers. I felt that with DevOps, the need was stronger than ever and that there was finally a playbook to make it work—and I had an unusual position of knowledge and familiarity with both the app security and DevOps spaces. On a personal level, I wanted to swing for something bigger. I think I would have done the same with Blaze if I’d had that opportunity, but I was left wondering what it would be like to build something larger. There was also a bit of a chip on my shoulder—wanting to prove that I could do it on my own. Mike, who joined as a co-founder after I started Blaze, is awesome, but part of me wanted to show that I could succeed without him. I had also grown more interested in the CTO role and had become much more informed about the business side. Before founding my first company, I was mainly a technologist. I remember asking Carl Snyder, an Ottawa-based product leader at Watchfire, whether becoming a product manager was a good path to becoming a CTO. He told me, “The best way to become a CTO is to found a company and call yourself a CTO.”

Pablo Srugo (00:08:01):
Yes, true, easy as that there, 100%.

Guy Podjarny (00:08:04):
That's what I did in Blaze. I found a company, I called myself CTO, and then I now found a company, I call myself CEO.

Pablo Srugo (00:08:11):
And so maybe tell me a little bit more, especially for a non-technical audience, what was it that you saw at this point the juncture 2015 in the security DevOps space?

Guy Podjarny (00:08:20):
Security has historically been very infrastructure-oriented. You could even say that’s still true today—it’s largely about patching servers, systems, and networks. Application security has always been the overlooked child in that world.

Pablo Srugo (00:08:32):
Is it like the firewall thing when you were talking about infrastructure?

Guy Podjarny (00:08:36):
Application security is more about SQL injection or sort of cross-scripting such vulnerabilities that are, well so the network securities are the firewalls, are sort of the server patch.

Pablo Srugo (00:08:45):
Right, when you mentioned more of an infrastructure focus that you're talking about.

Guy Podjarny (00:08:48):
Exactly—like misconfigured clouds today, except back then there was no cloud. Application security is more about vulnerabilities in your actual application code. Maybe you wrote something that lets someone log in incorrectly, or trick the system into throwing an exception that leaks data, or embed a piece of JavaScript in your page that steals information. Vulnerabilities like cross-site scripting and similar issues just weren’t being noticed at first. During my first decade in security, at Sanctum and then Watchfire, much of that early wave of application security was about convincing security teams that it mattered. Seventy-five percent of attacks and breaches happened at the application layer, yet only about twenty-five percent of the investment—probably less—went there. The problem was that application security wasn’t really under the control of security teams. Security teams were always close to IT, which was centralized, process-driven, and thorough, so they were aligned there. But application security lived in the world of software development, which moved fast. Security teams didn’t have the mandate to step in and say, “You can’t ship this because there’s a vulnerability.”

Pablo Srugo (00:09:56):
You gotta be looking at the code on a more regular basis and understanding what's changing.

Guy Podjarny (00:09:59):
It changes very quickly, and the knowledge required is highly specific. Suddenly you’re saying, “This form field can’t have non-alphabetic characters,” but it turns out that field is for someone’s address, and sometimes it includes special characters. Now you’ve broken functionality, and you can’t even ship a product to the right address. There are countless examples like that. So in application security, it’s always been a dance—trying to find vulnerabilities within complex applications and codebases. That was the first wave. Over time, the focus started to shift toward the idea of “shifting left,” meaning finding and fixing problems earlier in the development lifecycle instead of after the fact, when it’s much more expensive. I was talking about shifting left as far back as 2002—it wasn’t a new concept even then. But the problem was that developers didn’t want to use these security tools.

Pablo Srugo (00:10:52):
Because for a developer trying to put out features, this is just annoying.

Guy Podjarny (00:10:55):
Yeah, so this has been sort of this ongoing challenge, how do you put it in the build and all that. Now during that stretch of time, two things have happened. One, development has accelerated and the autonomy of the development team has accelerated. And especially with DevOps, there was a lot of continuous shipping, continuous delivery. So the opportunity for security to engage has kind of been taken away, right? Like it’s very, very hard for security to come along, multiple deployments a day, and definitely no place for security, no mandate for security to say stop or slow down. Everything was about sort of speed and autonomy. And so that made the ability of security sort of to find issues by themselves and their ability to scale and keep up with the pace, just like a non-starter. The second thing that happened is that IT teams have become modern and dev oriented and fast and suddenly you saw the world of IT ops go from being a call center to being like a business enabler to being sometimes something that is celebrated. Hey, these companies like Netflix, like Amazon, there are sort of great DevOps teams and because of that they are more successful, they can ship software faster. And so the premise is the need is greater and there’s an opportunity and a role model to transform. Can we do to security what has been done to ops? Can we create DevSecOps, which was the eventual kind of narrative.

Pablo Srugo (00:12:12):
And just to say back to you, like the idea being that DevOps got themselves to a place where they’re seen—and they are, certainly by developers—as helping developers ship things faster, getting to continuous delivery, and handling all these infrastructure things that devs don’t need to worry about anymore. But they understand that it’s because of this IT team that they’re even able to move so fast. And so now they’re aligned in their mission.

Guy Podjarny (00:12:30):
Correct, and I think developers but also the business. Before, the business would ask, what’s the minimum investment we can give this team, because they’re just the call center. Now it’s, we want to excel here because we want to be a company that can move fast. A lot of that change came hand in hand with the adoption of cloud and the fact that infrastructure became software—elastic, software-driven. That created cloud-native methodologies and DevOps. This evolution started with agile and scrum and team structures, then moved into DevOps. I’m old enough to have been through all of that. So the opportunity was to say, okay, let’s bring DevOps to security—and specifically application security. The core thesis of the product, or even the company, was that if you want developers to use a security product, you have to build a developer tooling company, not a security company. A big reason developers weren’t using these products was because they were really auditor products that had been shoved into a developer workflow. They didn’t care about developers, didn’t understand them, and didn’t align with their motivations. So Snyk was very intentionally a developer tooling company that happened to tackle security. That mindset was core to the ethos of the product. It even showed up in the color scheme of the website. We had debates about things like, when you’re building a developer product, it should feel warm and builder-friendly in its colors and tone—but when you’re telling a developer they have a high-severity vulnerability, it should scare them a little bit.

Pablo Srugo (00:14:11): 
Red, yeah, blood red, yeah.

Guy Podjarny (00:14:13):
Snyk's logo is a guard dog because animal logos were all the rage at the time. But it's also like an appropriate sort of security logo.

Pablo Srugo (00:14:21):
And did you just inherently understand all this because of what your background was or did you have to do customer discovery and these sort of classical things?

Guy Podjarny (00:14:27):
Yeah, because I think I had an early understanding of what DevOps really was because of my background in performance and building that out. And I had depth in AppSec expertise. I also built a team in London and Tel Aviv and brought together skills from both regions. It was very much about tunnel vision—I didn’t care about security per se, I wanted to build a developer tooling company. And notably, we could talk about go-to-market strategies, but I’ll say one thing here before pausing: that philosophy influenced everything—the whole being of the company. Who we hired, how we built the community, our transparency—it all reflected that mindset. But probably the most notable thing in hindsight was that we chose a product-led growth go-to-market approach. Bottoms-up. At the time, the PLG acronym didn’t even exist, but that kind of bottoms-up motion was highly unusual in security. There were a lot of learnings that came from that.

Pablo Srugo (00:15:17):
What is the value prop for a developer? Like why? Besides the branding and the fact that that’s your ICP, what are you actually telling them? Hey, you want to use Snyk because of what?

Guy Podjarny (00:15:27):
So first of all, it’s a great question. And I think a lot of it comes down to motivations. I’ve made over a hundred investments, and I get the benefit of learning from a lot of journeys. Maybe it sharpens my advice a bit, but one of the sentences I like repeating is, nobody cares about your product—they care about the problem you’re solving for them. And so you really need to think about who you’re solving the problem for, what the problem is, and what the need looks like. As a bit of a toolkit thing, there’s something called the power statement that I really like. It’s a sales technique—one of our team members, Gavia, found it in a sales book—but I use it as a product definition and messaging exercise. You build a three-part document that defines a sequence of motivations for your users. Developers come to Snyk because they’re afraid of dependencies; they’ve been burned by them. They hate rework caused by security findings. They see security as an aspect of quality and take pride in their work. Security teams, on the other hand, come to Snyk because they can’t get developers to embrace their security products. At the time, we were starting by focusing on open source library vulnerabilities, which security teams saw as a major threat. Then you craft a short one-liner—two sentences at most—about what your product does, intentionally minimized, followed by a clear differentiation statement. Your messaging should combine the core user motivation, what the product does, and how it’s different, and all of it needs to feel cohesive. If it’s not, it means your differentiation doesn’t match your customer’s pain—you’re over-rotating. We did a lot of these exercises to understand why developers cared, and I just listed a few of those motivations. We also leaned into how to engage and entertain developers, to get them to see the problem. Security is boring—it’s like insurance, all about risk and doomsday—but hacking is fun. Seeing hacking live is really fun. So we created a talk called Stranger Danger. Our initial focus was on the risks of using third-party libraries that might have vulnerabilities you don’t even know about, meaning you could get hacked because of them. The name Stranger Danger came from how kids are taught to avoid strangers—it’s a playful but serious analogy. We built fun hacker talks that showed people how easily things could be exploited. Developers would recognize popular libraries and think, “Wait, I use that library. Do I have that problem?” And we’d say, “Well, there’s an easy way to find out—you can use Snyk.” That created a visceral sense of motivation. And this ties into product growth. In anything you do, and especially when building a product, there are two axes: how much you care and how hard it is. You’ll only do something if you care more than it’s hard. One tool is to make someone care more—but that’s slow. The other is to make it less hard. And “less hard” is contextual. For a security person, access to code is very hard. For a developer, access to code is easy. But the security person cares more about vulnerabilities than the developer does. So finding that balance—understanding both how much they care and how hard it is—helps you motivate users while also making the experience easy enough that they’ll act on it.

Pablo Srugo (00:18:32):
For developers, the reason they care is quality. Most developers just want to write great code because they're proud of that and security's part of that?

Guy Podjarny (00:18:39):
The three reasons that kind of rattle off are the primary. I’d rank them as open source. Dependencies in general were just like a scary domain, so developers were looking for something. It was easy for them to believe that a dependency can fail them. And so they were just looking for things that would give them easy visibility to separate the good from the bad, because they’ve all had backward compatibility breakages and things like that. So it might not have been security per se, but just some form of hygiene about their dependency was a motivation. There were people that cared about quality, security as quality, and started taking pride, especially those that were DevOps forward, because they started caring about infrastructure and deployments, they started hearing about cloud misconfigurations over there, so that was a good early audience. And then I think a lot of it was about that rework, you know, around this notion of like, I will find these problems ahead.

Pablo Srugo (00:19:30):
And not have to rewrite code later, which is annoying for everyone.

Guy Podjarny (00:19:34):
Exactly, because it’s a big deal, especially when you choose a framework and you find out it was vulnerable, or sometimes you need to do like a major version upgrade. All that said, we started with a security threat of open source library vulnerabilities.

Pablo Srugo (00:19:45):
Is that similar to ChainGuard? I think I interviewed ChainGuard not long ago.

Guy Podjarny (00:19:50):
I guess I take pride that I think Snyk managed to kind of kick in motion a whole bunch of apps.

Pablo Srugo (00:19:55):
I think they'd be much after.

Guy Podjarny (00:19:57):
ChainGuard is like the evolution. Vulnerabilities in the open source libraries are an aspect of software supply chain security, which at the time was a term that didn’t even exist. It was long before that. When we came out, there wasn’t really an established category—probably BlackDuck was the closest thing, if you’d even heard of it. It was a very enterprise-y, kind of ancient tool, very unpleasant, and it did some security. But that’s what I was about to say—it was not a well-served problem. And there were starting to be examples of how it breached companies. Two years into Snyk, there was the Equifax breach, if you remember it—a massive breach, 300 million records—and that was a straight-up Java Struts issue, an unpatched, unupdated Java Struts vulnerability. It was so significant that the CEO ended up testifying in front of Congress.

Pablo Srugo (00:20:47):
Unfortunately, it's like the best possible marketing you could have had.

Guy Podjarny (00:20:51):
Security works like this—there’s a major breach, and suddenly everyone starts paying attention. But in this case, we happened to be dealing directly with that exact vulnerability. So we picked both the right developer-focused approach and a problem domain that was much more about motivating people to take action than about competing with others. There was a lot less competition, and it was an easier problem than static analysis or finding vulnerabilities in your own code, which are much more subjective and take longer to detect. Vulnerabilities in your dependencies are straightforward—if a dependency exists, it’s a database lookup, it’s a match. So we built a good database. We built hard technology, but it was much easier for developers to adopt. I think it was the right choice in terms of balancing difficulty and motivation—hard versus care—because static analysis, even though Snyk now has a great static analysis product that’s much easier than alternatives, is still a harder problem domain than open source vulnerability scanning.

Pablo Srugo (00:21:51):
And for a developer using this product, it just means they work with you to see the vulnerabilities in their dependencies, or you just patch it for them and they know that they're working on something that's safe?

Guy Podjarny (00:22:01):
One of our perspectives when we think about developer versus auditor is that an auditor’s job is to find problems, and a developer’s job is to fix them. And so everything in the product from day one—from about a month into the company, when we shipped this little beta product—included not just finding an issue but fixing it. In open source dependencies, the fix is almost always an upgrade. We also introduced the ability to patch. Sometimes you have a library that’s vulnerable and doesn’t have a fix, so in 2015 we added a feature that let you patch it yourself. It was often just a line of code—you’d install the old version of the library, and we’d layer on that one change to fix the vulnerability. People were terrified of it. They had a really hard time accepting it, even though it worked great and never broke anything. For years, we never had a single case where it broke an application. But the resistance was so strong that we eventually stopped offering it. People preferred to stay vulnerable rather than patch. And you mentioned ChainGuard—funny enough, today one of ChainGuard’s newest offerings reintroduces patching vulnerabilities. I was just talking to Dan Lawrence the other day. It still makes perfect sense. Why wouldn’t you? It’s very common in the operating system world. But at the application layer, people change slowly.

Pablo Srugo (00:23:09):
I know we’re getting specific, but part of it was just to get into that mindset, because I think even non-technical people know developers. And so they kind of know that ICP, and I’m just trying to understand what value you’re providing them. So let’s move to the PLG piece of it all. I mean, you know, bottoms-up PLG is so sexy, especially these days. Everybody wants it because it feels like, oh my God, if it works, it just kind of happens—Dropbox, Slack, whatever—you just grow for free. But it’s exceptionally hard to get off the ground. How did you do it, especially at the beginning, from a standstill? How did you get those first hundred, first thousand developers on?

Guy Podjarny (00:23:41):
So if you allow me, before I go there, I want to explain the lay of the land in security—then and now, actually. Security is a market that lends itself to a top-down sale, and for good, specific reasons. First of all, it’s an asymmetric game. The attacker only needs one entry point, while the defender needs to plug them all. It’s an unfair game for the defender, which means CISOs always need to be on top of buying new solutions. Every time a new technology comes out—serverless, containers, mobile, AI—there’s a new set of security threats. And typically, that brings a new breed of security vendors to help tackle them. So you end up with a very fragmented world. It’s hard for a CISO to accept that one director of engineering will use one product to secure open source vulnerabilities and another will use a different one. They want to govern it centrally, because the fragmentation is already so hard to manage. On top of that, it’s a very hard-to-measure domain. Does a product actually protect you? If it does, how do you even know it matters? It’s like insurance. You put a great new lock on your door and nobody breaks in—does that mean it was money well spent? Maybe you wouldn’t have been attacked anyway. So it’s a subjective space Because of that, security as an industry became very wine-and-dine. The CISO or security leader holds a lot of power, and their perspective—something you can influence over dinner or through trust—matters enormously. That’s just the reality of the field, and it makes it kind of murky sometimes. So bottom-up doesn’t really work in this world. It’s not an empowered space, and definitely not for developers. What changed with Snyk was that in AppSec, security could still be centralized, but if developers didn’t use the product, it was dead in the water. The constant frustration security teams faced was: how do we get developers to actually use this? There was a real need for developers to embrace the product. Our view was that the big problem to solve was developer adoption. If we could get developers to use and love it, the money would come later—which, by the way, took a while to happen. That was the thesis. Developer tools can go bottom-up because the minimum unit of value is small. I think a lot about what I call the “minimum unit of value”—the smallest value proposition that’s truly valuable to someone. In the developer world, it’s a single developer on their desktop writing code or building an app. For security, the minimum unit is usually governance, which happens at the business unit level. But developers are empowered, so DevTools win bottom-up—you have to win over the developer first. How did we get users? Basically, the same way all other dev tools did. We went to conferences, wrote content, and built integrations. Our big break was open source. We built a developer tool with great DX—developer experience. We launched a simple command line interface tool. It was free, easy to use, and you could download it, run it on your app, and it would tell you if it was vulnerable. At first, we didn’t even require a login. Later, we started asking for one to enable certain scans. Then you just kept using it. People would download it, we’d present it at conferences—this was after Akamai, so I had enough credibility to get keynote slots. We got a few dozen, then hundreds of people trying it, using it, saying good things about it. But they weren’t putting it into their build. They weren’t using it regularly. They’d use it once and stop. So we kept pushing to understand why. We reached out, spoke to users. I flew around a lot—living in London at the time, spending a ton of time in the U.S.—trying to figure it out.

Pablo Srugo (00:27:33):
To meet with developers one-on-one, to go to their office?

Went to meetups, to any meetup that would take me. I’d have seven people in the audience, fifteen people in the audience. I just chased them around. That was a heavy travel year. I literally flew to give a presentation where only three people showed up.

Pablo Srugo (00:27:49):
Especially for a free product, you're like, even if they all use it, like I'm not, it's not like I'm making a $50,000 sale. We have 10s of thousands of people who have followed the show. Are you one of those people? You want to be part of the group! You want to be part of those 10s of thousands of followers. So hit the follow button. 

Guy Podjarny (00:28:05):
It was, but you don’t know where it will come from, right? And you work, and you build relationships, and you invest in these people, and you understand what motivates them. It’s just a lot of conversations, and really most of them I did myself. I had a great team—they also did a bunch of those. I was the road warrior, and a lot of them handled things locally. As we learned, we really tried to think about what the barriers were. Eventually, we concluded that putting Snyk into the build was just too hard. There were two main parts to that. One was technical—they had to go off and do another thing they weren’t immediately motivated to do, like run a new test in the build. The second was that the build test is a gate. If you have vulnerabilities, and they’re not urgent, putting them in the build would break it. Breaking the build is a big deal—it’s like pulling the cord on a manufacturing line. And even worse, if a new vulnerability was discovered in a dependency you were already using—meaning nothing changed in your code, but the world just learned that one of your libraries was vulnerable—suddenly your build would break even though you didn’t do anything. That’s not a good experience. So we eventually figured out we could create a different view—a GitHub app integration. We built an app that connected directly to your Git repo. At the time, the security controls around adding integrations were more relaxed, so it was easier to do. The app would add Snyk into your workflow. We’d find your source code, tell you if any of your libraries were vulnerable, and every time you made a pull request, we’d check if you were adding a vulnerable library. It was all about engaging at the point of change—the moment you were making a decision, like Google’s “intent moment.” If you were adding a vulnerability, that’s when we’d notify you. We didn’t block anything—you could still push through if you wanted—but by default, we’d tell you. Why wouldn’t you want to know that you’re about to add a vulnerable library? And when a new vulnerability was disclosed, we’d tell you by opening a fix pull request. We’d literally hand it to you on a silver platter—an automatic PR that upgraded the dependency to a secure version.

Pablo Srugo (00:30:05):
Which again, you can decide when you fix or how urgent it is relative to every other priority you have.

Guy Podjarny (00:30:09):
So you can choose how you react, but it was a very easy and it became this like, why wouldn't you? We also created this sort of badges you can add to your repo to sort of take pride of the fact vulnerability zero.

Pablo Srugo (00:30:20):
And still free product at this point?

Guy Podjarny (00:30:22):
Still free. I’ll talk about money in a sec, but it was still free. We also reached out to open source libraries and got them to install it. That was a big deal because it created this sort of viral loop—every time you opened a fix pull request on a repo that someone was watching, they’d get an email. That became a means of distribution and visibility. And I want to point out that I kind of hand-waved something in there. When I said we look at your library and see if there’s a vulnerability—meaning, at the repository level, we check if you’re using any vulnerable libraries—dependencies don’t actually work that way. You use ten libraries directly, and they pull in two hundred others. You don’t know that unless you build the application. And building the application is per-project, different every time, very custom. So we built a pretty hard piece of technology that could approximate the dependency tree—it resolved it without actually building the app. That allowed us to give you that analysis automatically. It wasn’t perfect, but it was good, and it was technically challenging to build. That innovation really enabled a great user experience. It was very UX-driven. You could just click next, next, next, add all your repos, and immediately get visibility into which vulnerabilities you had. And because you were already integrated, we could start providing continuous value. So we can talk about money, but in terms of the breakthrough—the best moment amidst all the small improvements—I think that GitHub app and the open source approach were a big part of getting the first wave of users.

Pablo Srugo (00:31:49):
Did you see with those changes the sort of word of mouth that leads to true PLG and referrals? Because at some point the meetups don't add enough juice.

Guy Podjarny (00:31:58):
So yes, this was definitely an inflection point. From the early days, we had some of the best developer adoption numbers for a security product—which, to be fair, meant they were still pretty mediocre compared to a regular dev tool. For a dev tool, we really weren’t that awesome. We joined Heavybit, which was a sort of dev tools accelerator—now it’s a VC that focuses on dev tools—and I felt really embarrassed by my numbers compared to everyone around me, even the ones that didn’t make it anywhere. But we were in security, so we broke through as a security tool for developers. As a general developer tool, though, we were only lightly adopted. Still, our users were in the thousands, and then we started broaching the tens of thousands. They were continuous now. But what they weren’t doing is paying. So when we talk about PLG—when we launched that GitHub app, we also GA’d. We said, let the floodgates open, come pay us. We were very generous about it: for a month it’s free, then you can sign up or whatever. It took us a moment to realize—they’re not going to pay. They’re just not going to pay. And the payment was only $20 a month. That was a sobering moment. We also started thinking about the runway.

Pablo Srugo (00:33:06):
How much did you raise at that point?

Guy Podjarny (00:33:08):
So this is about a year into the company, maybe a year and two months. I had raised a $3 million seed and had probably spent about half of it by that point. There are really two stories that come out of this—one on the personal journey, and one on the PLG side. I’ll quickly share the personal one first, just to give context, but since we’re talking about product-market fit, I’ll circle back to that after. Around November of that year—Snyk was founded in July 2015—we had launched the initial CLI beta in October, spent about seven or eight months searching for the right path, and by June 2016, we launched the GA and the GitHub app. Then, by September, I realized it wasn’t making any money. I started talking a lot more with security people and made peace with the fact that the buyer was going to be a security person, not just a developer. Around November, there was a wave of inbound from investors who saw the external usage, saw that it was a security company, and assumed there must be revenue behind the scenes. Everyone was interested, everyone was willing. By early December, I bit. I kind of kicked off a preemptive round—told one investor, “Hey, there’s a lot of interest, about to get a term sheet over here.” Everyone engaged. I even got invited to a partner meeting at Andreessen Horowitz, stayed over the weekend to present—and nobody converted. Everyone basically peeked behind the curtain, saw there was no revenue, and said, “Oh, classic dev tool—some usage, not even amazing numbers, but nobody’s paying for it. Come back when you have more traction. We’d love to maintain the relationship.” And around the same time, my father-in-law passed away. It was a really sad moment—a hard December, personally and professionally. Ed Sim at Boldstart came through massively. He topped us up with a seed extension at the best number we got, though it was a small check. It gave us just enough runway to keep going. We got a little bit of conversion—not the right terms, not the right investors—but it kept us alive. That bridge really helped us continue through the next stretch, and by around September of the following year, I’d say that’s when we really broke through. So that’s the personal side of the story.

Pablo Srugo (00:35:14):
No, that was helpful. Yeah, what was the unlock? Because I also want to make sure we touch on Tessl a little bit. But what was the unlock on the monetization?

Guy Podjarny (00:35:20):
So the key lesson I’d share is this: what we missed was that, yes—developer, developer, developer—that’s the user, but that’s not the buyer. When I talk about product-market fit, I actually separate it into two things: product–user fit and product–buyer fit. I think we had cracked product–user fit, which is critical for PLG. But PLG works best when the distance between the user and the buyer is small. The best-case scenario is when the user is the buyer. You use the product, you love it, and at some point, you hit a paywall—maybe you upgrade, maybe your team grows, and the monetization feels natural.

Pablo Srugo (00:35:50):
It’s kind of full alignment, because then you just focus on product. When you find founders who say it’s all about product, they’re usually in that kind of situation—like Notion, Slack, Dropbox, or whatever. The product’s great, people use it, and people pay. That only works when the distance between the user and the buyer is small.

Guy Podjarny (00:36:03):
It’s harder, yeah, exactly. The second best scenario is when the buyer is the user’s boss. The user falls in love with the product, brings it to their boss, and it can still work. But the further away the buyer is, the harder it becomes. For us, the distance between the developer and the security person was substantial. And we neglected the needs of the security person. We didn’t think about governance. We didn’t think about the fact that security teams need breadth of coverage. If I’m a JavaScript developer, I couldn’t care less if you support PHP or not—it just doesn’t matter to me. But if I’m a security person, I can’t have five stacks, each using five different tools. So we spent the following year expanding governance, reporting, enterprise organization coverage, and stack support. We started out very Node.js focused, then expanded bit by bit, but we needed to scale fast. It was a grind. As we built those out, about a year later, we crossed a real chasm. There were a couple of breaches during that time—the Equifax one being the biggest—and that gave us another tailwind. Two years and two months in, we were at $100,000 ARR. Not awesome. We had burned $4 million by that point. Four months later, we were at $650K. A year later, we were at $4.5 million. A year after that, we hit $19 million.

Pablo Srugo (00:37:21):
Wow.

Guy Podjarny (00:37:22):
And so, so the numbers really like started escalating at that time.

Pablo (00:37:25):
And that motion I assume was like find an organization we have a bunch of developers using it and then now with all these governance pieces that you added, go sell up top.

Guy Podjarny (00:37:33):
Well, I think there were two sides to it—the product aspect and the GTM aspect. From a product perspective, we had to build all the capabilities around threats so the product wasn’t just enterprise-grade, but also matched the breadth and needs of a security user. From a GTM perspective, we started evolving what I call a “pincer movement.” We kept working bottom-up—getting developers to use it and, in smaller companies, going straight from the user to the buyer. We’d get the developer to refer us internally to the right person. That still worked, and sometimes it was quite productive. But the bigger the company, the more we needed to pair that with an outbound motion. We’d reach out to AppSec leaders and say, “Hey, did you know that seven developers in your organization are already using and loving Snyk? Do you want to talk?” For a while—and hopefully still today—Snyk became a kind of modern indicator. If you were using it, it said something about your company’s culture and forward thinking. I also did a few other growth hacks. I started a podcast called The Secure Developer, before podcasts were really popular, where I’d give a stage to forward-thinking AppSec people to tell their stories and share their practices. And again, taking a page from the DevOps playbook, we built a community around DevSecOps and launched DevSecCon, investing in that ecosystem. So we weren’t just building a company—we were building a movement. And that naturally leads into the Tessl story as well.

Pablo Srugo (00:38:43):
Yeah, so now we’re going to fast forward like crazy because this is still, what—2016, maybe 2017—that we’re talking about. Let’s jump all the way to 2023 or 2024. You’re doing hundreds of millions in ARR at Snyk. When did you start thinking about the next thing? How does Tessl happen?

Guy Podjarny (00:38:58):
So Snyk’s about ten years old now. Around five years into the journey, I brought in this amazing guy, Peter McKay—I’d known him for many years—to be CEO. It was opportunistic, but also a great complement of skills to mine. There’s a whole story behind it, but after a lot of deliberation and long conversations with him, I convinced both him and myself that it was the right move. He joined the company, and we grew together substantially—especially through COVID. I was leading forward-thinking product strategy, driving acquisitions, and shaping broader company direction. But after a while, I started to ask myself: what’s my role now? What do I want to do next? So I took a sabbatical to clear my head and sort out my thoughts.

Pablo Srugo (00:39:38)
In when '22?

488 - Guy Podjarny (00:39:38):
Yeah, at the end of 2022, I took a proper sabbatical—five or six months to really disconnect. When I came back, I decided to return part-time and started working on Snyk’s AI strategy at the beginning of 2023. But the more I dug into that, the more I caught the bug again. I just wanted to focus entirely on that space. And because Snyk secures software development, you can’t really think about its AI strategy without forming a broader thesis on where software development itself is headed. The more I explored that, the more I realized—that’s what I wanted to build next. The last step was just admitting to myself that I’m an addict. I love building. And I wanted to do it again.

Pablo Srugo (00:40:11):
When did you leave to formally start Tessl?

Guy Podjarny (00:40:13):
At the beginning of 2024, I resigned. I stayed on the board for about a year, but after a while, it became hard to balance the two passions. I’d lost enough day-to-day context at Snyk that staying deeply involved would’ve required more time than I could give. So now I advise, support, and stay very close to the company—but I’m no longer officially on the board. And from there, I went on to found Tessl.

Pablo Srugo (00:40:35):
Yeah, what is Tessl? I mean, there’s so much happening in AI and development right now. Where does Tessl fit in? What unique opportunities do you see?

Guy Podjarny (00:40:40):
So Tessl is built on the belief that in an AI world, software will move from being code-centric to being spec-centric. Today, software is defined by code. You start with some requirements, write the code, then throw those requirements away—and you repeat that cycle over and over. Eventually, the code itself becomes the only definition of what your product is. Nobody really remembers the original functional requirements. That knowledge just lives in people’s heads. Over time, that lack of clarity makes code slower to change. Every update risks breaking something. The more complex the product, the worse it gets, until you eventually have to “map back out” what your product actually does just to rebuild it. We think large language models can change that. You can capture what you want to build—in a document or structured spec—and let the AI write the code. That’s the future we believe in: spec-driven development. We’re building a platform to define and support that paradigm. What does a “spec” look like? How do you debug it? How do you observe a running system or version it? What’s the ecosystem around it? Tessl’s goal is to answer those questions and build the right infrastructure for this next era of software development.

Pablo Srugo (00:41:51):
Is this similar maybe to what people are doing on the front end, which is like you want to just design something and the code just spits out and you change the design, change the code, but now it's more the back end logic where you would be doing it?

Guy Podjarny (00:42:01):
So yes and no. The idea of natural language–based programming is happening everywhere—Lovable, Blot, all the AI agent frameworks where you give an instruction and something gets built. The key distinction for us is that in our world, you actually write down what you want to happen, and that becomes a long-lived asset. Over time, more of the weight shifts onto that asset—the spec itself. We talk about this as a journey: from spec-assisted development, to spec-driven, to spec-centric software. To explain that, it helps to look at where it starts. In the first year, we focused on the destination. It’s more than just prompting. Today, most of the knowledge lives in the code, and the prompt just tells the model how to modify that code—it depends on what was written before. The future we’re building toward is one where the code is unimportant. You have a requirements document that defines everything that matters, and the code can be regenerated at will. That’s the vision—but it’s still a future state. We’ve spent about a year figuring out how to connect that future to today, because current LLMs aren’t yet good enough to fully realize that vision.

Pablo Srugo (00:43:01):
The idea being that, as a PM, you’d just iterate on the requirements over time, and the code would update automatically in the background. You wouldn’t really care about the implementation—you’d just work inside this living requirements document.

Guy Podjarny (00:43:11):
Yeah, I think specs can exist at various levels of resolution. They can be very detailed or quite high-level—kind of like how a manager guides a team. That’s essentially what you’re doing: guiding AI labor. You can give light instructions and let the team—or in this case, the AI—make decisions. But then you have to think about what information sources it has to make those decisions correctly, and how you’ll verify its work. In other cases, you might be very specific, outlining exactly what needs to happen down to implementation details. So specs can vary. It’s not just one document—it’s an architecture of specs. You start to think about reusable specs, so you’re not reinventing the wheel each time. You don’t want a different logger for every system in your stack. The key learning here, though, is that this vision is anchored in the future—and that’s important for a startup. This will happen, and we’re going to build it. But today, it doesn’t quite work. For a long time, we wrestled with the question: where do we start? The right starting point became clear with agents. Agents do everything I described—but faster. They code faster, but they also forget faster. They create spaghetti code faster. They get you into trouble faster. You end up with code that’s fragile, inconsistent, and lacking institutional memory. The agent you open tomorrow has no idea what yesterday’s agent did. So agents need specs. They need guidance on what to build. And even once they decide what to build, they need to capture that intent in a spec, so that future agents remember why certain decisions were made. That way, when something goes wrong, you can tell whether the agent built the wrong thing—or just failed to execute it properly. At a company level, you also need a way to coach your agents: to define your policies, your internal platforms, your best practices—even down to how commit messages should look. You need a way to distribute that knowledge into this fast-changing agent space, and to evaluate whether the system is actually following your guidance. That’s the starting point for what we see as the spectrum of development. And in our current thesis on product-market fit, that foundation—anchored in how agents actually work today—is already showing pretty compelling demand.

Pablo Srugo (00:45:24):
Where does this fit relative to a Claude Code or something else that people are using daily?

Guy Podjarny (00:45:27):
It integrates on top of Claude Code, so it essentially makes agents better. It’s a better development methodology for working with those agents—a way to manage them more effectively. There’s a platform aspect, where Tessl helps define how things should be built, and an app dev layer, ensuring that what’s built gets stored alongside the code as a living “document of intent.” That intent file stays linked to the codebase, capturing not just what was built, but why. Over time, more of the weight shifts from the code itself into the specs, as they mature and accumulate experience. Eventually, you’ll be able to do things like say, “Upgrade this from Spring 7 to Spring 11,” or “Make it faster,” or even “Create a Christmas version,” or “Localize it for another market.” You’ll be able to make those high-level requests confidently because the system’s structure and intent are already well defined. At that point, the LLMs—the AI labor—can focus on optimization and experimentation, while staying within clearly defined intents, guardrails, and sandboxes. There’s still a lot to build, but that’s the path forward for Tessl: turning specs into the core of development and giving AI agents a stable, intelligent framework to build within.

Pablo Srugo (00:46:37):
And what stages is the company at now?

Guy Podjarny (00:46:39):
So we raised an early Series A for it and so we are well funded. 

Pablo Srugo (00:46:44)
I assume that was relatively easy, given your background at this point.

Guy Podjarny (00:46:47):
Yeah, it was. But I’ve been really fortunate with the people around me. I’ve got great investors—Boldstart, GV with Tom Hume, Index with Carlos, and Accel with Philippe. All very strong partners. And I’ve got an amazing team that humbles me every day. We’ve also built out a community even before the product fully launched—an AI-native developer community. We host a podcast called AI Native Dev, which I co-host with Simon Maple. I’d encourage you to check it out. We also run a recurring conference under the same banner, and that community has really taken off—around 70,000 people now when you count followers and subscribers. It’s a broad, engaged audience of people who care about AI development. The product itself is still earlier stage—it’s in closed beta right now, with many users giving us great feedback. Stay tuned for AI Native DevCon on November 19th—we’ll have some big openings to announce. We also launched an open beta for part of our platform, a spec registry, and the early response has been really encouraging.

Pablo Srugo (00:47:44):
And just quickly, when did you raise the A and how much was it?

Guy Podjarny (00:47:46):
We raised $125 million in total—about $25 million in seed and $100 million in our Series A. The last round closed back in September. I’ll say this—I’m in an unusual position as a founder. I don’t always recommend raising that much early, but for us, it made sense. I say proudly, and publicly, that I have zero interest in building something small. We’re building big. The world is messy, and we wanted the ability to go long and build for that future without worrying about short-term constraints. That raise gave us the freedom and the right partners to do that. I think we’ve also demonstrated good discipline—we’re using the money well, not pre-spending it. Sure, we lost some optionality by raising ahead, and I’m fine with that. The priority now is being disciplined, which is exactly how we’re operating. Practically all of that capital—by a large margin—is still in the bank. For us, this raise was really about autonomy and having great long-term partners for the journey.

Pablo Srugo (00:48:42):
Okay, cool. Let’s stop it there. I’ll ask the three questions we always end on. This can be for Tessl or for Snyk—whichever makes the most sense. When was the moment you felt like you’d found true product–market fit?

Guy Podjarny (00:48:52):
Yeah, for Snyk, it’s pretty clear. It was that stretch between August and December of 2017. We started getting inbound after inbound—from the tailwind we’d built in the developer community, security teams started reaching out too. Suddenly, every conversation was an inbound one. And that following year was all about figuring out how to handle the volume—how to manage all that demand. That’s when it really clicked that we’d found product–market fit.

Pablo Srugo (00:49:12):
And then last question, just based on everything, you know, hundreds of angel investments, your story with Snyk and then before selling to Akamai and now with Tessl, like what would be some of your number one piece of advice for an early stage founder?

Guy Podjarny (00:49:26):
Well, first, you want to anchor in the future—build something that in five years will be more important, more needed, not less. Your most precious resource as a founder is your time. The worst outcome isn’t failure—it’s getting stuck. You build a company doing $2–3 million ARR, growing 30% year over year. It’s enough to survive, but not what you signed up for. You can’t quite walk away, but you’re not where you wanted to be either. So think carefully about where you’re headed. Have a big vision, but take small, deliberate steps to get there. If you don’t know your destination and you’re just filling a gap that exists today, you’ll end up wasting years. This is the venture world—aim high.

Pablo Srugo (00:50:15):
Love it. Well, Guy, thanks so much for spending the time and it's been great.

Guy Podjarny (00:50:19):
Thank you.

Pablo Srugo (00:50:19):
Wow, what an episode. You're probably in awe. You're in absolute shock. You're like, that helped me so much. So guess what? Now it's your turn to help someone else. Share the episode in the WhatsApp group you have with founders, share it on that Slack channel, send it to your founder friends, and help them out. Trust me, they will love you for it.