Merrill Lutsky (00:00:00):
We ended up basically having to take all of our calls from this tiny Airbnb, and we were like, everything was closed. So we were living off of Cliff bars and, you know, just doing back-to-back pitches and trying on this shitty Airbnb Wi-Fi and trying to somehow pull the round together at that point. It's really helpful, especially in the early days, to have a product that users are interacting with every day. And as much as possible, as you build a business, if you're going to be doing this for five/ten years, having a founding team that you deeply trust, that you know. That you work well together with. That I think is, I can't emphasize enough, like how important that is. And that moment when we went from, you know, from having teams or like organizations within the Android, or some organizations within the Android using Graphite to now, like, every single engineer at the company is relying on this every day. It was kind of the moment when it's like, okay, we've really built something that's valuable.

Previous Guests (00:00:57):
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 Strugo (00:01:09):
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. Merrill, welcome to the show, dude. It's great to have you here.

Merrill Lutsky (00:01:24):
Thank you. It's great to be here.

Pablo Strugo (00:01:26):
Man, so you're on this like height, you know what I mean? Like, from the outside looking in, you never know really. It's kind of like, you know, what startups. I'm just, this analogy is coming to my head right now. They're kind of like relationships. You know, you see people together, and you kind of assume, oh man, they just click so well. You know, they're doing, you actually have no idea. Who's in a great relationship and who goes home and everybody's sad and/or they're fighting or whatever. Startups are similar. Like, you only get the TechCrunch headlines. You know, in your case. $52 million round from Accel, Series B. You had a Series A few years ago. $20 million round from A16. I have to assume everything's going well, and I'm sure you guys are crushing it. But only you know the chaos that I'm sure is inside like every single startup.

Merrill Lutsky (00:02:07):
Indeed. There's always so much more to the story. And I think even for us, it has been kind of this case of the many-year overnight success in some ways. Certainly, there are some companies that have even crazier stories there. But for us, I think, and this is repeated twice for us, really, in that at the seed, Graphite, for those of you who don't know, was a pivot from different dev tools that we were working on and emerged from a tool that we built internally. To help ourselves with code review. And that itself was kind of a year and a half, like a journey through the forest of trying different dev tools ideas, like not finding anything that was really working. And I think we had like six or seven months of runway left at the time when we raised the Series A. So even back then, it was, you know, it was very much like this is sort of the last-ditch effort to make this company work. And you know, thankfully. Really found a problem and found a product that resonated with a lot of engineers out there. And then, you know, even again, I'd say that kind of repeated itself from the Series A to the B in some ways in that we, you know, we raised, when we raised the A, we were six or seven people on the team. So, very early on, totally pre-revenue, entirely in closed beta with, you know, the good. A good group of users but very far. Very much building just an individual product. Like, quite far from, you know, from having something that we felt ready to charge for and to get out to market. And it really took us some time to get it to that point and get it to the level of quality that we were proud of and that we felt was ready to, like, launch and go out to market with, and even then, I think it took then a couple of pricing changes, figuring out our enterprise sales motion, and sort of this massive wave of AI code generation, I think, to really. And fortunately, we were kind of building the right thing for that moment. But I think all those factors had to converge for us to see the 20x revenue growth that we saw last year and the Series B kind of emerging from that. So yeah, lots of challenges and lots of times that we had to chase things up along the way.

Pablo Strugo (00:04:32):
It's crazy what you say about six months of runway to raise an A. And it was obviously a good A, $20 million from A16. You can't really ask for more. But my point on there is, it's more the rule than the exception that even the companies that end up doing very well, and you're certainly on that trajectory, actually go through moments where things could have been only marginally different and maybe the startup is no more. Like sometimes as a founder, you feel like, man, if I'm going through this, like what are the odds I'm really gonna, maybe I'll make it through this, but like what are the odds I'm really gonna become a success if I'm this close to just like complete failure? But, you know, there's companies that, sure, they just kind of are always crushing. But even of the companies that end up being successes, most of them have a handful of these, like, you know, just one that we did recently called Pinecone raised over 100 million. There was a point at which they pitched 40 VCs, all past that one meeting left. And it was kind of four months of runway, make or break. And, you know, they ended up making that happen. And then since, like, after that, you know, fundraising, you know, for many different reasons, became really easy. But yeah, it's a wild journey, man. It's a wild ride.

Merrill Lutsky (00:05:35):
Yeah, for sure. I mean, even in the beginning, I remember the very first. The week that we raised our seed round was actually the, I think it was, second or third week of March 2020. It was like the week that COVID really hit the states. And the three of us were out in San Francisco. We booked this tiny Airbnb because we thought we'd be out, you know, going around to pitch meetings all day. And we had a couple of meetings in person where, you know, the VCs would do like the foot tap or, like, you know, some wanted to shake hands, some didn't, and then we'd go sit in like a non-air-conditioned conference room for, you know, for an hour and then talk about the business. And nobody really knew how COVID was spread at that point. But, We ended up, you know, we ended up basically having to take all of our calls from this like tiny Airbnb, and we were like, everything was closed. So we were living off of Cliff bars and, you know, just doing back-to-back pitches. And try on this like, shitty Airbnb Wi-Fi. And trying to somehow pull it around together at that point. So yeah. And even, even kind of once we, we were fortunate that we ended up having a few different offers that we're really excited by. And, you know, Homebrew ended up doing the seed in terms that we were thrilled with. But even then, I think we kind of, you know, Graphite kind of emerged from the chaos of, you know, Greg moving from, you know, moving from SF to New York and not having toilet paper in the first, the first week, you know, not being able to buy anything here. It was, it was sort of this, this like, from the very first days of Graphite. I think there was a lot of crazy things for us to overcome. Emerging from that, I think, has made us really resilient and able to take on anything that comes our way.

Pablo Strugo (00:07:21):
So, you know, you grew 20X last year. You know, things are obviously really clicking now, but it's taken a lot of pivots. And I want to go deep into all of the choices you made along the way, obviously the relevant ones. Before we do that, just tell us maybe quickly, like, what does Graphite do today?

Merrill Lutsky (00:07:37):
Graphite is a code review platform built for the age of AI. And what we mean by that is we want to help teams deal with how they review and how they test and how they merge all this code that's now being created. For many years, this outer loop of development of how we test, how we review, and how we merge and deploy code that's always really been the bottleneck for a lot of large companies.

Pablo Strugo (00:08:05):
Is this like reviewing pull requests? Is that kind of the stage that you come in?

Merrill Lutsky (00:08:08):
Yes, pull requests. That's always been the bottleneck for how software is built at big companies. They're not really constrained. They have thousands and thousands of engineers. They're not really constrained by how quickly they can build the feature. A lot of times what's really blocking is the rest of that process. This problem has been made pretty much many times worse now by all of these AI code generation tools where these are amazing tools that give engineers leverage like they've never had before and let them create tools and build features much faster than they've been able to previously. But it's making this problem even worse in that now you have even more code changes that engineers are creating. And we're trying to then push them through the same process for how we review and how we test and how we merge them. The same set of processes and the same set of tools that we've used for 10-plus years just aren't really working anymore. And that's really the problem that Graphite solves. We take a lot of the best-in-class workflows and tooling from the best companies, like Facebook and Google. Have pioneered and then make them available to combine that with Graphite. Coming up with a lot of AI tools to help accelerate the review process. We have an agent that will review every code change in a few seconds and give feedback instantly versus having to wait several hours for a human reviewer. And we basically put that all together in one end-to-end platform and make that available to any team that's building on GitHub. So today we have companies like Shopify, Snowflake, and Figma, many of the largest and fastest-moving teams out there that run their code review process and their outer loop on Graphite. And it's helping to accelerate, to like, save them hours and hours every week that they're using it and cut down on that back-and-forth review time.

Pablo Strugo (00:10:02):
And you started working on some other version of Graphite in 2020, like right before COVID?

Merrill Lutsky (00:10:07):
So we actually started working on a different Dev tool. It was something completely different than Graphite. Actually, the very first thing that we built when the three of us on the founding team got together looked more like what Gem Dev is doing now, which is kind of a loom for developers. We wanted to help engineers and PMs capture bugs and log all of the network requests and console logs and put that all together and then push that into Linear or your task tracker of choice. We built an early version of that.

Pablo Strugo (00:10:42):
When was this? What year?

Merrill Lutsky (00:10:43):
This was the first thing. This was 2020. This was the first thing that we built when we came together. We would share that with a few friendly companies. We got some users on it, but it wasn't the type of thing that we saw getting the kind of daily usage that we wanted to get, and that really felt compelling. And we kind of fell into this cycle where we'd ask for feedback. I think it was kind of a classic mistake of like, we asked for feedback. Users would give us feature requests. We'd build the feature requests, and then nothing would happen. We'd look at the metrics, and they were using it just as little as they were the week prior. We did that a few times. We iterated on that for a few months and eventually just weren't really seeing the traction that we wanted. One of the things that we've learned from that. Kind of pointed us at the next idea, though, was a lot of companies were asking us about having something like this for mobile. And that led us to sort of the second thing that we built, which was a platform for rolling back native iOS apps, much like you can roll back a web deployment. The problem here that I'd seen at Square and Greg had seen at Airbnb, Tomas, I met as well, was when you release a native iOS app, if something goes wrong with it, you can't really roll it back quickly. You have to go through the App Store resubmission process and get it reviewed. And even if you expedite it, it can be hours or days even before you get that fixed out to users. And imagine if you're a Fintech company or something like that; that can be a really critical amount of lost revenue or revenue. Lost actions and user trust. So what we built was a tool that lets you basically package two successive versions of an iOS app together and then roll back on the end user's device with that feature flag without having to go through the app store submission process.

Pablo Strugo (00:12:39):
And this was like you were dealing with bugs, so that's why you got kind of looped into this other part of bugs, which is bugs in mobile apps.

Merrill Lutsky (00:12:46):
Exactly. Yeah, we kind of. But we saw a lot of the pain that users were telling us about was it. Was more on the mobile side than web. And that was kind of what it was, somewhat orthogonal, but was what led us to play around with building something for mobile and found that idea. That was sort of the second thing that we built, was this iOS app. That one we got a little further with. So we had a few customers. There was one large Fintech company, a couple of other consumer apps that were using this, and agreed to pay for it. But the problem that we had, I guess two problems that we saw with this product, was one was that it was very technically hard to build. We were building on a lot of kind, of unstable Apple APIs. Many of them were undocumented. Also, there's just so many different ways that every company builds their iOS app differently or uses, like, a ton of different frameworks or different CocoaPods, you know. Some are using. Some are using, like, different. Different packages and different ways of compiling their app. That basically meant that every single.

Pablo Strugo (00:13:54):
And the outcome of that is what? Just, it makes onboarding for you really hard or makes it kind of like buggy, or what's the business outcome?

Merrill Lutsky (00:14:01):
It makes it difficult for us to successfully. We had to account for all these different edge cases in figuring out how to insert the feature flag properly and how to dedupe where all the frameworks and assets were for that app so that we didn't balloon their app size. That level of customization that was required for basically every single customer we onboarded just ended up being really difficult for a team of four of us at the time to support technically. So, I think that was kind of lesson one was, like, don't build on, you know, ideally don't build on an unstable technical foundation, especially as a startup, like technical risks. Unless you have really deep, like, outside, really deep, like, outsized knowledge advantage there. It's just not really worth it as a startup to build that. If you want to build on something undocumented, you know, you really need a big team that can handle the amount of uncertainty there. The second piece I'd say, the second lesson that we learned there, was it's really hard to build as a startup when you only have use every couple of weeks or every month. And for us, that was the case because when you think about an iOS app release cycle, you're only really doing it once every few weeks. Every two weeks is pretty common. We'd basically get one shot to get it right. And if we missed that, if something went wrong at that moment, we just got skipped from the build process, and they'd say, like, okay, come back next month. We'll try it again. And that just ended up being making the iteration cycle really long because we basically have to then go back. Try to fix the problem. Try to replicate it as much as we could on our side with incomplete information. And then go back and try it again and have that be, you know, have that be like, see if we, if we got it right. And if not, do the cycle repeat itself? And I think that for us, another critical learning was, it's really helpful, especially in the early days, to have a product that users are interacting with every day. And as much as possible, I think, either through, you know, through APIs or, directly, you know, having daily usage of this is really, really important.

Pablo Strugo (00:16:03):
For stickiness or even just maybe just for learning, like for you as a product builder?

Merrill Lutsky (00:16:07):
It’s important for stickiness, certainly, but I think just for iteration speed, it’s critical. And I think it speaks to — it really then helps you to learn what’s broken with it and helps you to get the level of feedback that you need. And I think with Graphite, by contrast, like, you know, Graphite, we say, is next to the IDE, is the tool that engineers spend the most amount of time in per day. (context: IDE, or Integrated Development Environment, is a software suite used by developers to write, test, and debug code — examples include VS Code, IntelliJ, and Eclipse.) They’re constantly just spending hours every day, like looking at pull requests, reviewing them, moving them along in the process, and merging them. All of that, working in our CLI to create them — (context: CLI, or Command Line Interface, is a text-based interface developers use to execute code-related commands directly.) There’s just so much energy and time that’s being spent in this tool that anything. We end up often times faster than GitHub has a status page up. We know when there’s a GitHub outage, for instance, because we have users that are just on this every second of every day and are taking actions. That’s just — the speed of that feedback loop for us is so powerful. It really helps us make sure that we’re — it helps us create the quality of product experience that we do because you just have that constant stream of feedback and, you know, signal — you know, signal of whether something is wrong or not.

Pablo Strugo (00:17:25):
By the way, like, throughout this whole time, were you funded, or how were you kind of keeping the lights on for you four?

Merrill Lutsky (00:17:31):
That was after. So we raised our seed round right at the start of the company. So we had $2.5 million at that point, and we were purposely trying to be very efficient at that point and not spend too much capital. Try to extend that runway for as long as possible while we were in that early iteration stage.

Pablo Strugo (00:17:54):
Maybe just on that, actually, the origin story, like how did you three come together, and why did you decide to start a startup in the first place?

Merrill Lutsky (00:18:01):
Yeah, so Tomas and Greg and I were all really good friends from Harvard. Tomas and Greg had been project partners in all the really hard CS courses and had worked together a ton. Now, I was a couple of years above them in school, but then I took a year off to go and build my first company, which was a YC startup called Podmetrics, building customer feedback tools for hotels and restaurants at the time, and ended up doing YC. This was like a winter 2013 batch. Went through YC, raised some money, built a small team, and ended up having a small acquisition out of that. But then I decided to, you know, unlike my more successful Harvard dropout compatriots. Decided to go back to school and finish. And that was kind of when I met Greg and Tomas, was through the startup community on campus. And we ended up spending a lot of time together. Tomas worked after graduating. Tomas came to New York and worked at Meta out here. I was at Oscar Health and then a few other startups in the New York area. And we'd always kind of work from each other's offices and talk about things that were happening in the tech world and strategy and that kind of thing, so.

Pablo Strugo (00:19:13):
Like, that initial product was a problem. One of you had themselves?

Merrill Lutsky (00:19:18):
Yeah. So this was largely inspired by, like, my work as a product manager, wanting to have something that felt more like this. Also, there was a tool, Meta had a tool, I think it was called BugNub internally, that basically did this, that would capture screen recordings and console logs and everything and put it into their internal pass tracker. So it was a similar idea of taking what we'd seen at large companies and making it available to everyone, and we also knew Greg was working on Airflow and some of the other data infrastructure at Airbnb. He was also very interested in DevTools. I think all three of us that had interacted with and worked on DevTools in the past and all had this thesis of, like, can we just take what we've seen at big companies? What I'd seen at Square and Oscar, what Tomas had seen at Meta. What Greg had seen at Airbnb and Google. And from there, I think take some of those ideas that we saw working really well and make them available to every startup from day one.

Pablo Strugo (00:20:28):
That, on the surface, sounds like a no-brainer. And frankly, I think most people would think that. And especially because you're a developer yourself, you're working. You're using these tools. You rely on them. You think they add value. And yet when you go out to market with it, you kind of get stuck in this, oh, yeah, if you add one more feature, sure, yeah, yeah. And then, you know. Never really takes off. What was broken in that kind of logic chain? What do you think didn't work?

Merrill Lutsky (00:20:51):
Yeah, I mean, I think some things are features, not products or companies. And I think that what we. And also some things I think can only, can't really exist as standalone companies. They only really, they're only really like internal tools that they can't really break out from that because they don't, they don't immediately, you know, while they solve a problem, they don't immediately match up to like a strong business need. And they're just too low priority in order to actually get evaluated and get brought in. And I think that's one of the things that was difficult about that first idea was it wasn't solving a burning pain. It's a nice tool to use, but nobody was really losing their job or losing sleep, spending a ton of time replicating this internally. Versus something like, I think if you look at something like code review, it's like developer efficiency is much more of a core business problem, like how fast can we ship, especially, I think post, we saw this happening a lot, kind of post-2022. Like market correction, where all of a sudden, there are tons of layoffs, teams are being halved in size, and still held to the same roadmaps. And all of a sudden developer efficiency becomes this huge, huge priority where if you can make an impact on that and you can help teams ship faster, give developers back hours and hours in their day, all of a sudden that's much more a core part of the workflow. Also going back to the earlier point around daily use, like being part of a, I think, like, you know, you can build a feature at a big company that gets used like, you know, once every few days, once every few weeks, like that's totally fine. But if you want to, like, really build something of value that you can charge a good price for as a SaaS tool, like, it really, I think, has to be that type of, like, daily-use core workflow, something that someone is spending all of their time in for them to really feel like that's adding value and for it to really be delivering that value to them.

Pablo Strugo (00:23:04):
I spent so much time, as a C-stage investor, besides the team. I spend the most time thinking about the must-have-ness of a product because there's so many things that are ROI positive, that make sense, that are useful. And the key question is, you just need so much pull and velocity to be successful and truly get to that product market fit and, really get past that early stage in, you know, the amount of time you want. You don't want to be there for seven years, and you need that must-have-ness to get that okay, so it's like now you're on kind of the end of that second. Let's say, pivot, which is this mobile rollback thing you're learning these lessons. What year is it? Is it like 2021 now?

Merrill Lutsky (00:23:43):
This is 2021. Yes.

Pablo Strugo (00:23:44):
And what's the next move?

Merrill Lutsky (00:23:46):
So the next move for us was deciding. The critical moment for us was deciding to pivot to code review. So this happened. It's like spring of 2021, the beginnings of Graphite emerge, when we started to hire our first few engineers. So we brought on a couple of Tomas's ex-co-workers from Meta. They come into the room. We're getting them set up on our tooling, and.

Pablo Strugo (00:24:11):
And this is just to be clear. You're hiring them to work on the mobile rollback?

Merrill Lutsky (00:24:14):
To work on the mobile rollbacks, yep. Our lead designer and then our first couple of engineers. We brought in to work on the rollbacks tool. And we bring them in. We set them up on GitHub. We're showing them, like, okay, here's how we do code review here. And something really interesting happens, which is they have sort of this allergic reaction to it immediately. And one of them said, like, this workflow makes me feel like a caveman. And it was just such a strong reaction to it.

Pablo Strugo (00:24:46):
Because they were used to just, like, a different world, a different way of releasing.

Merrill Lutsky (00:24:48):
Because, yeah, they've come from. They'd come from Facebook's internal tool called Fabricator, which was a much different workflow, a much more streamlined tool, really designed for and optimized for, like, large, fast-moving teams building in a Monorepo, you know, with high trust versus, like, the world of GitHub, which is, like, much more generic, you know, emerged from the world of open source, you know, much more optimized for that, like, large mini repos, not working with trusted co-workers, trusted contributors necessarily, problems of community versus problems of how do we ship as quickly as possible. I think that was really the, and specifically there was this workflow called Stacked Diffs or stacked pull requests that Meta and Google had both kind of developed internally, which basically lets you parallelize the review and development process. So I'll explain sort of how that works. So in the GitHub world, let's say that you're building a feature, and you probably have backend components to that, model changes, like API changes. You have, like, your front-end code. You might have multiple clients for that. And in many cases, that's either gonna be like many different pull requests and many different repositories, or more likely, it's going to be just one massive PR that needs to be reviewed. And that ends up being you end up getting, having to put that PR up, add your reviewers, and then wait for them to give you an approval. And while you wait, you can't really do anything else. You have to either find some orthogonal code to go work on or just kind of sit on your hands or find something else to do. And especially in a world of distributed teams, this can be really annoying because let's say your coworker is halfway around the world, whom you need to unblock you. You push up your changes, you wait, you go to sleep, they wake up and give you a review and say, hey, you need to change these things. You go back and do that, re-request the review, go to sleep again, and they wake up, and maybe then they approve it and you wake up and merge it and two days have gone by and you've been unable to make progress on anything else in the meantime. Compare that to the Stack diff's workflow, which says, basically, if you can take each of those pieces, any atomically reviewable or mergeable piece, make that into a separate pull request that's changed together in this dependency stack, the way. What you can do is, let's say I write my model changes, I push them up for review. I can keep going and keep working on the next piece in that stack.

Pablo Strugo (00:27:40):
It's almost like modular pull requests. I don't know if that's a good way of looking at it, but.

Pablo Strugo (00:27:43):
Yeah, it's modular, thinking about it as really breaking it up into these chains of atomic pieces that can be reviewed separately. And the beauty of the tool, though. Is that if you, let's say that, you build your model. Changes you build your API changes. You build some client work on top of that. Even if you have to go back and change something, the beauty of the tool is that it lets you propagate those changes up through everything you've stacked on top without having to resolve the same conflict every single time.

Pablo Strugo (00:28:16):
Got it.

Merrill Lutsky (00:28:16):
That's why this is really hard in vanilla Github without any tooling. You basically have to sit there and constantly resolve that same read-based conflict all the way up.

Pablo Strugo (00:28:25):
You love this show. You don't want to miss the next episode. Why would you? So hit that follow button. Trust me, it's in your own best interest. That tooling was. What they had built internally at Facebook and Google?

Merrill Lutsky (00:28:37):
Yeah. So that, you know, the end result is that instead of this like stop-and-start, like blocking workflow that many, anyone who's worked at a company and used GitHub is familiar with. What you end up with is this kind of parallelized review and development process where you can always work on the next most important thing. While you do have to wait for an approval to merge, you don't have to wait for a review to keep working on top of your previous changes. And you also don't end up in a world where you have multi-thousand-line pull requests that nobody wants to review. The efficiency gains of that are just massive. And I think if you look at companies like Meta, where they managed to scale to tens of thousands of engineers all working in the same repo at a time and merging and deploying constantly, a lot of that, I think, is attributable to them developing this workflow and really pushing that on all their engineers to work in it. That was kind of like the magic that I think everyone who's worked at one of those companies, and I'd seen this workflow at Oscar, which used the open-source fabricator, which was Meta's internal tool. There's an open-source version that spun out at one point and then went end of life in 2021, actually, which is part of why we ended up thinking about building this was the available open-source version of Fabricator went end of life at that point. Basically, we'd all seen this before, and I think almost every engineer who's worked with Stacked Diff previously misses that when you bring them into an environment that doesn't have this workflow. So basically, we bring in Nick and Jacob, who were our first two engineers, both ex-Meta engineers. Both of them kind of are complaining about GitHub, feeling slowed down by this. Tomas had also felt this. They ended up in one of our, we were doing like some week-long, we do like a week-long hackathon every quarter. We still do the, it helps generate some of the best feature ideas that we've had. But basically for one of their hackathons, they recreated the command line part of the meta tool internally just so that they could use it. And it worked pretty well. They really loved it. They were happy with the tooling that they built and the ability to stack PRs again. And you know they use it. We don't really think that much of it for a while, but at some point I think word got out that we built this and, among the ex-Meta community and 

Pablo Strugo (00:31:24):
And was there a vacuum, like, by that? First of all, maybe tell me even more about the fact that that other thing got like sunset or whatever. Like, why did that happen? And it doesn't leave a vacuum where everyone's like. Dude, like, I need something to replace it.

Merrill Lutsky (00:31:35):
Yeah. That was strong. That was like one of the main factors that encouraged us to think about, like, could this be applied? Would others be interested in this and created a lot of the interest that I think there was when that announcement happened? Basically, it was an ex, one of the early engineers at Facebook who had created Facility, which is a company that was running the open-source version of Fabricator, basically it sounds like they never really wanted to make it like a large company like the CEO of that company wanted to, like, really wanted to just, like, focus on family and not be investing so much in the business and decided to, like, stop maintaining it, and so that created a lot of, like, ex-Meta engineers encouraged a lot of them to go look for something else that would let them use this workflow, and that, you know, around that time, you know, word got out that we had built a tool internally to do this. And we started getting a lot of inbound from ex-Meta engineers. And we'd also, we also experimented a little bit. Once we started doing this with, you know, once we got that it's inbound, basically saying like, Hey, I heard you've built this. I heard you built this thing that lets us do Stacked Diffs on GitHub. Like, can we try it? And this kind of snowballed a bit to the point where sometimes we'd demo, we'd be demoing the iOS rollbacks tool, and there'd be an ex-meta engineer on the other side who'd say, you know, this is, this iOS stuff is cool and all, but like, you know, tell me about the Stacked Diffs thing that you've built.

Pablo Strugo (00:33:07):
That's crazy. This is the market pulling it out of you. Like, the most obvious way possible.

Merrill Lutsky (00:33:13):
Basically, it was, you know, I think the product market fit is the sort of, like, amorphous, intangible concept. But it is the type of thing of like you're kind of like a relationship, like you're going back to your relationship analogy. It's like, you know, what. When you have it, you know, when, and that I think 

Pablo Strugo (00:33:32):
What is love? What is the product market fit? Yeah, same answer. And this is what? This is near the end of 2021 now at this point? Like you four?

Merrill Lutsky (00:33:40):
This is like summer, fall, yeah, summer 2021. And basically at some point it becomes too loud to ignore. The iOS product isn't doing quite as well. And we basically decided, like, hey, this thing seems to have lags. Let's try to make a run at it and see what we can do. We only have a year or so of runway at that point. So we said, This feels like. This has a lot more of the type of pull that we want. Let's go all in on this and see what happens. And we basically designed a test to make sure that we had the level of interest in this to warrant completely changing the company's direction and abandoning something that had customers that wanted to pay. And the test was basically. 

Pablo Strugo (00:34:31):
How much revenue were you doing on your old business?

Merrill Lutsky (00:34:34):
I think we were only in the tens of—I forget exactly, but I think it was probably in the tens of thousands of—I don't think we'd even collected. Anything at that point, but we just have commitments.

Pablo Strugo (00:34:44):
Like $10K MRR or $10K ARR sort of thing? Like $700k ARR?

Merrill Lutsky (00:34:47): 
I think it was probably like $30K to $50K of ARR at that point. In terms of commitments that we had. It just wasn't really where we wanted to be. But obviously it's not nothing.

Pablo Strugo (00:35:01):
It's something, yeah, you know, you still want to be sure you're going to give it up.

Merrill Lutsky (00:35:05):
Yeah, so what we said was basically, like, let's work entirely on what became Graphite for a month. And we said, if by the end of the month we can get to, I think it was 20 or 30 engineers at companies that we know, like, known companies, like, good engineering organizations that are using Graphite, like, every day for work, then we'll go all in on this and we'll say, like, okay, that's enough signal.

Pablo Strugo (00:35:30):
For free or did you want to get paid for it?

Merrill Lutsky (00:35:32):
For free.

Pablo Strugo (00:35:32):
Okay. It was just a usage. You wanted them to rely on it.

Merrill Lutsky (00:35:35):
Just the usage. We wanted them to rely on it. We wanted them to use it every day. And the other piece that we did was we said, if you want to use this, we're not going to collect payment for it, but we'll put you in a shared Slack channel with everyone else who's using it. And we'll set up a half-hour weekly Zoom call. So we referenced The Mom Test a lot. We wanted to make sure that we were in some way collecting payment in the form of time invested in this to make sure that it was something that engineers were excited enough about to warrant meeting with us every week, which for many engineers, reducing meetings is pretty important.

Pablo Strugo (00:36:17):
It's a high cost.

Merrill Lutsky (00:36:19):
Yeah, 30 minutes is. We wanted to make sure that it was like, this is something that you're serious about using. And I think we ended that month with 50. That grew to 100 in the next month. Yeah. Really, it quickly became apparent that this was something that engineers wanted to use. You were getting this constant stream of feedback. Of feature asks, bug reports, a lot of really positive feedback, a lot of requests, and a lot of things were wrong with it, but I think that just the volume and the frequency of feedback that we were getting just indicated to us, like, okay, we're really onto something. And that's sort of when we decided to. I think it was a pretty clear pitch then to our investors, who were excited about the traction. The team who were excited about having something that was homegrown develop into the focus of the company. For everyone, I think it made a lot of sense. And it was a pretty obvious decision for us to make at the time. And that was kind of what got us to. That was what really put us on the path to building, going all in on Graphite, raising the series. Launching our waitlist that fall and then raising the Series A. 

Pablo Strugo (00:37:33):
Kind of like that, I guess, because you went all in probably in Q4 2021, you raised an A like mid-22s, like six months later, something like that?

Pablo Strugo (00:37:41):
Yeah, at the beginning, I think it was, yeah, it was the beginning of like February, March 2022 is when we raised the A. We launched our waitlist. It was like right before Thanksgiving in 2021.

Pablo Strugo (00:37:54):
When? Where were you? I guess, like, I mean, that part of 2022 was still, like, the second half of 2022 was terrible. The first half, the first quarter of 2022, was still good. Like, but where, what was the company at, like, high level, you know, revenue-wise, customer-wise, where was the A?

Merrill Lutsky (00:38:06):
Yeah. So we were still pre-revenue. On the, like, pre-revenue at that point. We did shut down the other product. It was really just based on the amount of traction and excitement that we got from our waitlist launch. So we were on the front page of Hacker News for like a day and a half. We got like several thousand engineers signing up in the first 48 hours from that.

Pablo Strugo (00:38:31):
And I guess there's also a point of like the caliber of the engineers, I assume, that were using this.

Merrill Lutsky (00:38:36):
Right. I think that was the big thing, was that it wasn't just like hobbyists. It wasn't like random signups. It was like engineers of places like Netflix, Snowflake, and Ramp, like really good companies that were signing up for this. And we also like we implemented it such that if you got, we did a kind of a viral waitlist mechanism where if you convince. Like, you know, four teammates to sign up as well, then we'd bump you to the top of the waitlist and onboard you sooner. So that really helped us a lot to get to, like, encourage teams to sign up together versus just individuals.

Pablo Strugo (00:39:17):
And why did you wait so long to just make it? Like, what is the business model, and why did you wait, you know, like six months plus to turn it on?

Merrill Lutsky (00:39:24):
So the business model is we charge per seat, like per seat per month for, like, our core code review product, and then. 

Pablo Strugo (00:39:33):
What's, like, just the price range-ish? What, the starting? Starter package or?

Merrill Lutsky (00:39:37):
If you're under today, the pricing is if you're under 10 or fewer engineers per month or 10 or fewer engineers on your team. It's free. After that, if you're over that amount, it's either $29 or $25 per seat per month for the core code review platform and then $20 per active committer per month for our AI code review agent, Diamond, which you can. You can use either together or separately from the core platform. If you use Diamond and Graphite Core together, then we give you a discount on the combined.

Pablo Strugo (00:40:14):
That makes sense. And then what was the strategy like early on? How did you, because obviously you want that maximum growth, you want that maximum usage, but you also want to show revenue? How did you think through, you know, leaving it free for X amount of time before turning on kind of monetization?

Merrill Lutsky (00:40:27):
Yeah, so this was one of the difficult parts, was that. We especially as a developer tool. We didn't want to charge individuals. So we ended up, we knew it was going to be somewhat of a long journey from building the initial product, which is more of an individual-focused. Like the command line tool and then the web dashboard for reviewing code. We're much more like individual engineer-focused. You didn't need It worked on top of GitHub. You don't need your whole team to use this. It was much more of a much more of, like, an IC engineer-focused tool. And we knew that we needed to build into, like, deeper into the team and company workflow before we could charge organizations, which we knew is what we wanted to do. This is a little bit different. I think now with tools like Cursor and Windsurf, there's much more of an appetite for paying for tools individually. But at the time especially, I think we were really hesitant to try to build something and sell it to individual developers. It's notoriously difficult to get. The default for every engineer is like, oh, I'll just build this myself. So even if it doesn't make sense for them to do so, that's always kind of the mentality and one that we have ourselves as well sometimes. It's just so hard to break out of that. So we wanted to charge teams. We knew that we wanted to build. We basically wanted to, like, really nail the individual code review process and then expand into, like, adjacent tools that work. That kind of work really well with and helps teams scale this Stack Diffs workflow, so the merge hue is one of the first things that we built that lets you kind of merge entire stacks of PRs at once and coordinate the merge process would. 

Pablo Strugo (00:42:18):
You built all this before charging anyone?

Merrill Lutsky (00:42:21):
Yeah, we built a lot. We built a lot before we started to charge.

Pablo Strugo (00:42:25):
And then what is the sales motion? Like, once you have. Like, whatever people start using a kind of PLG, and then when you see a cluster of usage, you go up a level to VPNs or what's the kind of, what's the go-to market?

Merrill Lutsky (00:42:35):
Yeah, so in the beginning, in the beginning it was entirely self-serve. So we just had companies that would sign up, add seats, kind of grow naturally. We then added, really, it was only last, only in the last, like, I'd say a year and a half that we've built out more of the enterprise sales motion. So when we built the merge queue, that was the first thing that we really started charging for as part of the team plan. We've then expanded into having an enterprise plan as well. Some of our enterprise customers have been upgraded, where they'll start as kind of a self-serve on the self-serve plan, and then at some point we'll have a conversation with Eng-leadership. Sometimes for smaller companies, it's like a VPN. For larger companies, they have a dedicated dev infra team that's basically just focused on cobbling together some combination of off-the-shelf and homegrown tools on top of GitHub to accelerate their teams. And for them, Graphite is having a whole team now that's focused entirely on helping them solve this problem. is something that a lot of Dev Infra teams have appreciated and really resonated with. So that's generally where we go for enterprise. A lot of our traction, even at the enterprise level now, is still inbound. So a lot of times, the reason that we added an enterprise sales team was that we were just getting all these inbound requests where they couldn't off the tool self-serve. They wanted to go through their procurement and review processes. And for that, I think we wanted to make sure that we were meeting them. And the way that they're buying and evaluating tools. And I think that's really served us well and helped us to accelerate with teams like Shopify and Snowflake, Netflix, and some of the really strong teams that are using Graphite.

Pablo Strugo (00:44:34):
And how fast? When you, did turn on monetization? How fast did you get to, like, a million in ARR?

Merrill Lutsky (00:44:39):
We got to, so we got to a million in, I think it was nine, like, 10 months. I think since, from when we launched.

Pablo Strugo (00:44:46):
From when you launched, but not from when you turned on, like when you actually started charging. 

Merrill Lutsky (00:44:51):
I guess it was, yeah, it was about 12 months from when we started charging in the beginning. And we had, I mean, the nice thing was, like, we had that core customer, the core base of users in the closed beta. So we'd already built a good user base. A lot of them were already kind of at the scale where they were, you know, where they would need to roll onto a paid plan. This was actually one of the, I mean, one of the more nerve-wracking moments for us was like when we, when we flipped the switch and basically said, okay, now, now like. 

Pablo Strugo (00:45:25):
Time to pay. Yeah, time to pay up. 

Merrill Lutsky (00:44:27):
Time to pay up, like, yeah, you never, you never really know. And, yeah, I think we were really happy with almost everyone. Ended up converting onto Paid that was eligible to do. So that really, I think, showed the stickiness that we were seeing in the usage metrics ended up really converting nicely into revenue. But you never really know until you do it, and I think that was one thing that, you know, I think certainly we could have started charging earlier. But I think we really wanted to make sure that we got the product right and that we felt like we were 

Pablo Strugo (00:46:04):
Do you remember more or less, like, how many users you had by the time you started charging?

Merrill Lutsky (00:46:09):
It was. I think it was in the thousands of, like, daily actives.

Pablo Strugo (00:46:16):
Nice. And what are you at now? Like a hundred, like tens of thousands, I would assume.

Merrill Lutsky (00:46:21):
Yeah, now it's like high tens to like hundreds of thousands of active users on the platform.

Pablo Strugo (00:46:27):
Daily actives. That's crazy. Wow, that's awesome. That's huge, man. Well, congrats on the success, dude. It's been, I'm sure, a crazy journey.

Merrill Lutsky (00:46:35):
Yeah, it's been really exciting to see that, to like, see the growth. Even in the last, you know, now, especially to have kind of gone from, you know, gone from sort of this like, internal tool and something that like individual engineers of companies were using to now having like all of Shopify's engineers, like relying on, on graphite daily, it's really exciting to see.

Pablo Strugo (00:46:57):
And so let me, you know, one thing, one observation I had was it's interesting. You started off with this idea of taking tools that were working at large companies and bring them to everybody else. And then that first one didn't really work. You did some other stuff, and then you kind of ended up doing that anyways, just with it, with a different one. Which is pretty crazy.

Merrill Lutsky (00:47:15):
Yeah, I think that, the. We like to say that our high-level thesis was correct, but the entry point was wrong. Like, we, I think. That, there are a good number of other companies, like Statsig. Is one that comes to mind immediately, of, like, companies that have just done this playbook of, like. Take a really great internal tool and, like, build a version of it that's available for everyone else outside of the walls from which it came, and I think that we knew that that worked. We knew that, and we really deeply believed that the internal tool chains from companies like Meta are really well designed and have a lot of value to give to the rest of the world. But we just needed the right entry point and the right problem from that to really resonate with the market and give us the on-ramp to the development cycle.

Pablo Strugo (00:48:09):
Perfect. Well, let me stop it there, and I'll just ask the last three questions we always end on. The first one is, when did you feel like you'd found true product market fit?

Merrill Lutsky (00:48:18):
I think it was actually only, I'd say, only in the last year or so when I think the key thing was when we made our pricing, we made a change in pricing that better aligned with kind of how companies wanted to buy Graphite pretty much in a matter of like a couple of weeks, like more than doubled our revenue from that and saw a lot of, you know, a lot of strong conversion and growth after that. So that, to me, felt like the moment when. When, you know, everything that was what got us to, like, the first million, you know, growth had been slow before that, but that was the first time that it was like, okay, like this is, this is clicking, like everything feels, feels like it's really going well. And then I'd say another moment was our first wall-to-wall contract with a really well-respected company. This was last August, I want to say. Was when that closed.

Pablo Strugo (00:49:15):
And what's a wall-to-wall contract for you guys, is what? Is it six figures or does it hit seven?

Merrill Lutsky (00:49:19):
Six figures, yeah. I think that was our first six. Well, six figures for most. Our largest contracts are seven figures.

Pablo Strugo (00:49:27):
Wow, that's crazy.

Merrill Lutsky (00:49:28):
Once you get to the thousands of engineers, but. Yeah, like, that moment when we went from, you know, from having teams or, like, organizations within the engine within the sub-orgs within the engine using Graphite to now, like, every single engineer at the company is relying on this every day, like, that was kind of the moment when it's like, okay, we've really built something that's valuable. And that's, that's like a core part of the engineering workflow.

Pablo Strugo (00:49:53):
Did you ever feel like, especially going through those pivot hell periods, like maybe you wouldn't make it to the other side and this was just going to, like, not work out?

Merrill Lutsky (00:50:02):
Did you ever feel like, especially going through those pivot hell periods, like maybe, oh, yeah. I mean, there was. I think that, you know, we've now survived. I mean, a series of both, like, internally and macro events. We've survived a series of, like, really unprecedented times. And, you know, we weren't sure from the very beginning, like we weren't sure if the seed round was going to come together, if everything would shut down with COVID. We, you know, we thought we were going to, we thought we were likely to run out of money before the waitlist launch and even for Graphite. And even then, I think we. The night that we launched the waitlist was, I'm not sure if you remember the big AWS US West 2 outage in 2022. That was when it was down for hours and hours. That was the night when we were launching our waitlist. We were scrambling, trying to figure out, can we move to a different region? We'd never really thought. That was the one thing that we hadn't. We'd gone through this whole checklist of what's everything that can go wrong. The entire AWS region failure was just not something that was on the list. We also had all of our money in Silicon Valley Bank. When that collapsed. So, yeah, we've had a couple of, like, moments. Where we've really had to, had to kind of hold our breath and try to, like, do our best to get through something, something difficult. But I think that like now. Those were some of the highlight reels of pretty difficult times for us. But I think that now really the question is, especially as AI is changing software engineering so quickly, a lot of teams are just trying to figure out how to build most efficiently in this new age of AI tooling. Now, I think the challenge and the exciting thing for us is how can we help teams adapt to that world. How can we build that new developer virtual chain that helps them review and merge all this AI-generated code as efficiently as possible and as safely as possible. And, you know, to be able to, I think the fact that we now have teams like Shopify that give us a ton of feedback and that we're working with every single day on this, I think, is really one of the pretty exciting for us. And I think. Gives us a really strong position to, you know, partner with them and keep building great tooling that I started through teams every day.

Pablo Strugo (00:52:32):
And then just, you know, the final question. Taking, you know, you've gone through two startups now. This one was not like now you hit clear early-stage success and you're on a different trajectory. But, like, you went through a bunch of things to get here. What's, like, one big piece of advice you think more early-stage founders need to know?

Merrill Lutsky (00:52:53):
Yeah, I think I have a few I could go into, but I think one of the best ones, and I talked about this on a couple of recent podcasts I've done, is just the importance of having a team of co-founders that you trust and really work well with and communicate well with. I think I've seen so many early-stage startups that have struggled with, like, founder communication and founder breakups are just. The YC talks about how that's the most common cause of startup failures. Even a lot of, like, later-stage companies I've seen, like, even, you know, pure companies or companies that step ahead of us that have either, like, you know, imploded or had some sort of, like, buyer sale or something like that, you know, largely due to, like, founder conflict or, you know, founders, like, burning out or, you know, falling out in some way. And that, I think, has been one of the most critical pieces for, you know, getting through everything that we've had to get through is just, you know, having a team that we trust deeply, having co-founders that we'd spent so much time with before, we'd had deep friendships with, and just a strong basis of trust. Because I think when you're running out of runway and aren't sure what to do, and there's no clear path and no clear answer for you having. That's kind of all you have in those moments is you know is like the trust in your co-founders and the trust that you know together you can you can rise to that occasion and I think a lot of people are right now especially with the you know with like the boom in AI startups are you know there's so many people like rushing to found companies like  you know putting together an MVP and you know and you know all these vibe coding tools and in a few hours like  it's amazing that now these that these you know that you can do that so quickly but I think that you know ultimately when as you as you build a business if you're going to be doing this for you know five ten years having a founding team that you know that you deeply trust that you know that you work well together with that that I think is I can't emphasize enough like how important that is and, you know, how hard it, how hard I think it is to do that if you don't, you know, if you haven't known that person, if you haven't worked with that person before, if you don't have like a really deep, you know, deep basis of trust there. I can't imagine like doing like founder dating and started like doing that with somebody I've worked with for that. I hadn't, like, known for years prior.

Pablo Strugo (00:55:29):
That makes total sense. Well, Merrill, thanks so much for coming on the show, man. It's been great to have you have an amazing story. So appreciate you sharing it with us.

Merrill Lutsky (00:55:36):
Awesome. Paolo, thanks for having me. Yeah, excited. Always happy to tell more about the early days of Graphite. And I mean, hopefully it's interesting for everyone who's kind of navigating that early walk through the forest of product market fit finding.

Speaker 0 (00:55:52):
So picture this. It's months from now, years from now, and one of your founder friends. A really close founder friend of yours. Guess what? Their startup went bankrupt, and it turns out if you had just shared the product market fit show with them. They would have learned everything they needed to find product market fit and to create a huge success, but instead their startup has completely failed. You have blood on your hands. Don't let that happen. You don't want to live like that. It is terrible. So do what you need to do. Tell them about the show. Send it to them. Put it on WhatsApp. Put it on Slack. Put it where you need to put it. Just make sure they know about it and they check it out.