Ep. #47, SecureBuild with Grant Miller of Replicated

Grant Miller: All right, you're listening to the EnterpriseReady Podcast.

Benjie De Groot: And The Kubelist Podcast.

Grant: This is our very first crossover episode. So, you've got me, Grant Miller, the host of EnterpriseReady.

Benjie: You've got Benjie De Groot, co-host of Kubelist.

Marc Campbell: And hey, I'm Marc Campbell, the other host of Kubelist.

Benjie: It's pretty exciting to have a crossover episode. It's like we're in the '80s.

I'm very excited, it's like "Knight Rider" and "Baywatch". No, that's not.

Grant: I was thinking more about the MCU, but that's just me.

Benjie: I'm dating myself a little bit, but you know, like, there was like an episode of like "Growing Pains" I think and like some, I don't know, just the crossover brings back old memories.

But the important thing here is that we are going to do something that I've wanted to do for years with Kubelist and that is talk about kind of what Replicated does in the open source context, of course, and some other stuff too.

I think it's always interesting to understand about the business aspect and the go-to-market and all that stuff, but I'm really excited 'cause Grant and Marc also happen to be co-founders of Replicated.

And so, this is the big episode where we kind of get to talk about the history of Replicated and the impact it's had and is trying to have all the time.

So, I'm really excited to actually get an opportunity to go through all the projects that Marc and Grant have worked on over the years, and maybe some upcoming stuff, right, Grant and Marc?

Grant: Yeah, we have a really exciting thing we're going to announce today, so, that's why we're really bringing this together, is one of the biggest launches in Replicated's history.

Benjie: Wonderful. And it's open source-related, so that's Kubelist. That's why you're here.

Grant: Very, very open source-related.

Benjie: All right, why don't we start off a little bit, I think, typically, we have a very technical audience on Kubelist.

Obviously, it's a little different with EnterpriseReady, but we really like to understand the background of folks.

So, I mean, I'd just love to hear a little bit about your background, Grant, how you came into this world, and then, Marc, you as well.

Grant: Yeah, sure. So, I mean, the quick backstory that puts Marc and I together is we started a separate company together now that's like 13, 14 years ago, called Look.io.

And Look.io was sort of a live customer support chat, but for mobile applications.

So our first customer was Hotel Tonight, and we basically helped people as they were booking hotel rooms, talked to a customer support agent.

And that company was very quickly acquired by LivePerson after about from start to finish, nine months in and out.

You know, Marc and I were young and had never seen sort of the startup equity that we had earned turn into cash.

And so, we were able to turn that company around, sell it for a couple million bucks and felt like we were kings of the world for some amount of time until we realized that a couple million bucks is just not that much in this world today after taxes and the stock goes down and all of a sudden you need to get a real job again.

So, that's how Marc and I kind of came into the software world together.

And then we started Replicated over 10 years ago, and this has been basically really around a lot of Marc's early experience and kind of his entire experience around infrastructure and his career installing networks in prisons all the way through to being an application developer.

And we saw this opportunity to basically enable software vendors to distribute their applications into secure customer environments.

And we thought that would really change. And this is 10 years ago and we thought the technology that was enabling that was going to be Docker.

And that much has been true. I think like when we started the company, the idea that software would be self-hosted in the future was pretty heretical.

And we got laughed at, like literally investors laughed in my face. Some Salesforce exec laughed in my face when I told them that we were going to make on-prem software cool again.

But obviously that ecosystem developed a lot around Kubernetes and we've been kind of in the ecosystem for now, yeah, 10 years, building different products.

And one thing we'll get into maybe a little bit later, kind of in the EnterpriseReady side of the show is just some of the challenges that we went through as that market really shifted we had missed product cycles and just had other challenges that we had to address over the last few years.

But yeah, that's kind of the quick backstory to me and Marc.

Benjie: It's the origin story of Replicated. Marc, Grant talked about that you did networks at prison and stuff like that. Just from a technical side.

Because you know, I'm going to, the crossover, who's going to win here, it's going to be nerds versus enterprise, but we'll try and balance it out.

But Marc, on that note, just tell us a little bit about your technical background, like where you came up and just a few things about that.

Marc: Yeah, I mean, in school studied computer science, but like first job and spent the first bit of my career doing like more like IT work, installing networks and routers and stuff like this and servers and I think learned a lot about that process, which I think is, I don't know, I think it makes it really interesting and you actually understand how software and how computers work a lot better because of that.

I mean, to this day, Replicated is still building a lot of infrastructure software.

We're still like really active in Kubernetes and Docker and containerization and some of the new stuff that we're going to talk about here today.

So it's definitely like, stayed relevant throughout my entire career.

But like, I mean, I definitely am happy to have transitioned from IT work into writing application code and building--

Benjie: I mean, what was that, 20 years ago? Like, that was a while ago.

Marc: Maybe more, but yeah.

Benjie: Yeah. Fair enough.

Grant: But it's great. It's like, I always describe Marc as like the true full stack developer, right?

Like all the way from the IT side, the networking side, racking and stacking all the way through, he's building mobile apps at some point for very popular consumer applications and had that, the full breadth of knowledge of what it took to get applications into production, so.

Benjie: I like to think of Marc as a full full stack because he does like back-end, front-end, and infrastructure, but I've never thought about the mobile.

So would it be a full, full, full stack, like a triple stack?

Marc: Well, it's even more so with AI now, right? Like, I don't have to-

Benjie: Yeah, but you just think it and it's done.

Marc: Yeah.

Benjie: So, okay, so you guys started Replicated over 10 years ago and the idea was to, quote, unquote, "make on-prem cool again."

I think on-prem is definitely viable, important, critical. I'm not sure it's cool, but the mission is still in progress.

What was the first, like, let's talk about the first chunk of the Replicated journey. Like what was that?

So, you raised some money and you're focused on this new technology called Docker, and you're thinking about Kubernetes and that it's still early, it's pre 1.0, I'm pretty sure from that timeline.

And you guys want to attack this on-prem problem. What was kind of the first, what was the first few salvos? Like, how did you go about attacking that problem?

Grant: Yeah, I mean the funny thing is, Marc actually initially built some deployment tooling around Minecraft.

And so, that was kind of like the, you remember that start, Marc?

Marc: Yeah, we did, we were making it so that you could spin up your own Minecraft server and host it like really, really easily in like seconds, which was like wow at the time, right?

Because you didn't have to go figure out how to like get everything and all the dependencies and everything deployed.

Grant: And that kind of helped us be like, oh wow, this technology is super powerful. We can do something interesting with it.

You know, we saw the business opportunity around what Replicated would become, right?

Sort of this, hey, I always called it like the post-Snowden world where just like, I think we started to understand that like wherever data went, it could be like tapped into and so companies and countries would need more control.

And I thought we would just like have a little bit of a, like a recognition that like maybe multi-tenant SaaS wasn't the like be-all end-all solution.

And it actually makes a lot of sense, if you can automate software to allow your customers to operate that automation in their own infrastructure.

And we knew that eventually it would become more cloud-based, so it was never anti-cloud, right?

We always assumed that like the end customer would actually run software in their own VPC, not necessarily only in like a true on-prem data center, but you needed the software to be completely portable in the same way that it could run in a data center, it could run in a VPC.

And so, we had that thesis, we looked around the market, I thought we were going to get customers like Slack and Dropbox and Evernote to become like our first customers.

I was really focused on the SaaS side. And then we met Tom Preston-Werner from GitHub, an investor in both Replicated and Shipyard.

And he gave us a ton of insight. And that insight from building GitHub Enterprise was a lot of what led to us creating EnterpriseReady site, right?

It was like, here's what enterprises expect from true EnterpriseReady products.

And one of those things was a deployment option and being able to self-host, and we looked at what made GitHub Enterprise really good, like the admin console, how it worked, how it operated, how you configure some of the monitoring.

And so, we started to really build a version of GitHub Enterprise that you could basically deploy any application.

And Tom also introduced us to our first three customers , two of which were open source companies, so Travis CI, NPM, and Code Climate.

And those folks were kind of in the GitHub ecosystem, needed to self-host next to GitHub next GitHub Enterprise.

And so, they were all kind of early adopters evaluating containers. And so they were like, "Hey, yeah, we want to ship this container and we need to give customers an easy way to run it and operate it."

And so we wrote, Marc wrote our original, our own scheduler.

So we had something that was a little bit like a almost Docker Compose, like pretty simple, not quite all the functionality of Kubernetes but was designed to be, to help these enterprise applications get deployed, onto one or more nodes inside of a customer environment.

Benjie: Marc, that was like Mesos days and like when was that, right, when you wrote your own scheduler?

Marc: Yeah, I mean it was at the time I think it was like SwarmKit or something from Docker where they were talking about it and it came out, but you could run Docker containers, but overlay networks and surface discovery and all the things that we take for granted in Kubernetes was not there yet.

And so, we had to build something proprietary, basically. We didn't think it was general purpose, but it was easy to define here's five containers that run or multiple containers that run.

We weren't solving software-defined networks or anything like this, it was using host networking.

I mean, it's still out there being used a little bit today, but like, it was definitely when we saw the Kubernetes ecosystem start to take off, we were happy to like adopt that and get out of the world of building that layer ourselves though.

Benjie: Yeah. You know, Grant, I want to go back for one second just because again, it's a mixed audience.

So, I want to make sure everyone understands what on-prem means.

Can you just give me a 32nd explanation of what on-prem software means and your delineation between cloud and data center was helpful for me, but maybe just explain that again for like 30 seconds.

Grant: Yeah, so, it's a great point.

The word on-prem kind of comes from this idea that the data center or like that your, actually, your servers were on-premise.

So you would have servers in a closet in your office and you would install software in there, like you would install a CRM or install some other, some databases that were using and those were only accessible from your local network.

And that's kind of where the terminology for on-prem software came from.

What's happened, I'd say more recently, and I actually even stopped saying on-prem as much, and I say self-hosted because what this means is that it really differentiates between multi-tenant SaaS, right?

A software vendor deploys their software onto a cloud that they can control versus that software vendor packages up the automation, maybe gives you a helm chart and allows you to run their application on any infrastructure that you have access to.

And that could be a VPC within your AWS account or that could be a true on-prem data center.

And that methodology has become more important in the last, like I'd say five to seven years.

I think it's become a little bit of a mixed bag between these different hybrid deployments. People talk about BYOC, people talk about data plane control plane.

But what we've seen is there's been a real resurgence in interest in different deployment options that give customers more control of the data so that they're not sending their data out to thousands of different vendors, but instead bringing the applications to where the data already resides.

Benjie: Right and that's probably for security reasons, but also because in today's world, data seems like kind of you got to gatekeep that stuff for these big corporations. Is that the way to think about it?

Grant: Yeah, very true. So initially very much around security and compliance, but then to your point, proprietary data has become really powerful and important in terms of training these AI models.

And so, if you're sending your data all off to some SaaS service who has the rights to train on it and to own the learnings from your data, then you might have a problem with that because your data might be the most important data in your sector and then they could use that data and learn and sell something to your competitors.

So there's a lot of different reasons why I think folks are being much more thoughtful about where the data goes and who gets access to it.

And ultimately it just, you have to trust all these vendors. If you're sending your data out to thousands of vendors, it's basically the weakest security posture is your security posture.

If you have a thousands copies of something, whoever has the least secure environment is like, that's the security posture of your data.

And so, if you can control, bring the applications to the data, you can control who accesses it, you know what's going on versus sending it out there to thousands of different vendors.

Benjie: Totally. Okay, so let's nerd out for one sec here. Let's take, let's put the nerd brake on.

Grant: Yeah.

Benjie: So, okay, Marc, I'm a SaaS company, I'm a dev tool company early in Replicated's career.

You said Code Climate, I said Travis CI, I think you guys had Circle CI as well as a customer.

Why couldn't I as a developer there, like what are the main highlight challenges of why I'd use Replicated the software to do my software?

'Cause I'm a computer nerd, I think I know everything. "Oh, I could do it this weekend."

What were like the main nerd challenges, Marc, and then follow up, Grant, what are the main like business challenges for actually deploying on-prem?

But Marc, let's start with you.

Marc: Yeah, I mean like look, you can, right?

Like I think we worked with really technical customers who a lot of them that ended up becoming really good, Replicated customers were successfully actually shipping on-prem software before.

Travis CI had one, NPM had one, HashiCorp shipped Terraform Enterprise on-prem before they came to Replicated.

It's really the diversity of those customer environments that start to become really, really complex though.

You want to ship to five customers running in AWS, great, they're probably all pretty similar, but that's not the way the world actually works.

Like, you want to ship to 20 or 50 different enterprise customers. They're running in different cloud providers, they're running in different regions, they have different types of disks and networking configurations and everything.

And so, what we focused on was trying to build, like, there was a few different parts to it, but the part on the technical level that became valuable was building that interface, that abstraction around those different environments so that you could ship to your customer on AWS, next customer comes in there on Azure and you wanted to be able to run in that environment.

And we were able to actually give high confidence that it would actually work in that environment because we had been installed in those environments before.

We've gone through those battles before.

Benjie: Okay, so it's really like permissioning and upgrading, right? That's one of the big things that you guys.

Marc: Yeah. I mean...

Benjie: Like a path to upgrade on these different disparate environments. Like when you're talking about bad environments, are we talking about, we're talking about REL 5, right? We're talking about like barely containers on there, or what are we talking about?

Marc: Yeah, there's two, it's like that, right? There's this, like these early days Docker wasn't accepted everywhere yet.

Like, and some of these environments weren't compatible, but then also just like the environment themselves, you might be an enterprise customer that's running chef or puppet or something in a very more legacy way that's resetting that server all the time.

And so, any changes that you'd come when you deployed your software and you make to it, they'd get overwritten and reset.

And so, all of the stuff like that that we'd have to learn how to work around, detect, and then you don't want to sit there and try to do an install at a with your enterprise customer and then find out it didn't work and then have to like pull in an engineer and figure out why.

So like a lot of the software that we ended up building was stuff like pre-flight checks, you were able to validate that environment prior to actually performing the installation so that you knew it was going to, you know, work.

Benjie: Right and then there's also one of the thing that always interested me about your tech was the air gap stuff. So, talk to me a little bit about like what Air Gap means and like what the challenges there were.

Benjie: Yeah, a lot of these, the software, like you were talking about before the reason you'd bring it in on-prem is because you want to make sure that you're not sharing that data.

You're not sharing, you don't want to go to a multi-tenant SaaS, you don't want to share with the SaaS provider.

And so many of these enterprise environments don't allow outbound connectivity.

So you can't, you certainly can't get inbound connectivity, but even that, you have to figure out how to get that software running without being able to rely on apt repose or Docker hub or anything like this running.

So, we create an Air Gap package, which is essentially, it's a Tar Gzip of the application and all the container images in the metadata, but then cryptographically signed to prevent tampering with it and license.

And so you deliver this tar ball on into that enterprise customer environment. And then we would, I mean, over the course of Replicated, the solution changed a little bit as Kubernetes adopted more and more, we would just deliver into the enterprise registry that they actually had.

Benjie: Right.

Marc: And then you could perform the installs from there. But early on it was before Docker registries really were a thing that you-

Benjie: They weren't like ubiquitous in enterprise orgs.

Marc: Yeah.

Benjie: Wait, so, those pieces of software that you're installing, it's not just my application, right? It's not just Circle CI or Travis, right?

Which I want to say that was Rails. I think that was a Rails app I believe. I don't know.

Grant: Travis was, yeah.

Benjie: Yeah. But it's also the underlying database. It's Postgres. It's Redis. So, it's all the infrastructure of those applications, right?

So you're not just delivering this application, you also have to support like this version of Redis and that version of Postgres, is that right?

Marc: Yeah, I mean, it can be, right? And it can also be that your customers don't all look the same.

And some of them are running in AWS and they want to run Postgres on RDS, and some of them want to run it in a container or they have like their own way to run Postgres.

So you have to talk to their team. So, getting it to work in their environment is a big challenge. If you want your enterprise customer to run software, you want to not be super opinionated.

You want to kind of be able to like try to, when it's reasonable, meet their opinions about how that software should actually shape and look and run in the environment as long as it's going to be compatible.

Benjie: Right, but do you basically have been installing open source software and application software since the beginning of this whole thing is really the way to think about it?

Grant: Yeah, for sure.

Yeah and I would also just add like, I think the shape of the problem really changed as the landscape evolved, right?

So in the beginning, there was no Kubernetes, this is really even before there was Docker Compose. And so like we had to provide some orchestration, right?

And that was what our scheduler did. And then after there was Kubernetes, we had to provide some packaging.

So we had this product called KOTS, which was a way to basically package Kubernetes applications and leverage customize to do last mile configuration.

And then Helm really became the foundation for how people package. And so then and this kind of brings us to today's problem that we think about.

It's really about the entire commercial software distribution lifecycle. So, we sort of discovered that like basically every one of these software vendors goes through the same process, these seven different phases and stages.

It kind of mirrors the DevOps lifecycle, but it's a developed stage so that everyone would be familiar with that. It's really focused on you need to be truly kind of portable and secure.

And then it's a testing phase. And so, we built a really comprehensive compatibility test harness so you could spin up different versions of Kubernetes, different hardened images and test your application.

Then it came down to licensing. So we needed to provide licensing and entitlements.

It was around release and you need to give people release channels, the ability to kind of give customers different versions, to your point, upgrades.

Then we had to focus on installation. So how do you make sure this is easy to install if the customers has Kubernetes or they don't have Kubernetes.

We needed reporting so you know what's going on. Some telemetry, health checks, what's happening with these instances as they're running, as well as maybe some custom metrics.

Supportability, which is like, hey, there's an issue with this environment. Can I look and see what's happening? How do I support this customer?

And so, that lifecycle, we kind of have purpose-built solutions within each of those, and that's kind of what we call the Replicated platform.

And we try to continuously look at each phase and make sure that we can add a lot of value because ultimately the value that we were bringing eight years ago, five years ago, just doesn't have as much significance in today's world. And so, we needed to kind of change the value proposition for Replicated throughout that time.

And I think that's like a really interesting challenge that many businesses face because you kind of initially come out and you're attacking like a very specific need in the market.

But we see this in AI a lot, but then the market moves and changes and there's new dynamics.

And so, your team's ability to see those changes in the market, predict them and then kind of get ahead of what's happening is really important and I think is, in a ever-changing and ever increasingly changing world, it's an important skill that a lot of companies will continue to need to really develop. Because one thing that's for sure is that next year will not look the same as this year.

Benjie: You mean next week will not look the same as this week.

Grant: True.

Benjie: Yes. It's insane the pace of things. I don't think there is an AI yet for like replacing your C-suite every other week, but it seems like that might be coming sooner than later.

So, okay, so you've gone through a lot with Replicated, both of you have, obviously. You've gone through a bunch of product cycles, it's a very robust product.

As a application company I turn to Replicated and I say, "Hey, I need you guys to help me sell these big enterprise contracts."

And then you guys have, you're basically working in as hostile environment as possible for software and they're all disparate and it's all like that one company and they all have these various needs. So-

Grant: But I think my point real quick is it's also just all the tooling that you need around that, right?

So, it's the idea of you're not just doing that with one customer. You have a entire process and you have lots of different teams that you're coordinating in order to make that happen.

And so, there's, you need kind of specific tooling just like you need DevOps tooling, right?

You're not just like you don't just, we're not YOLOing it up to get push Heroku Master anymore, right?

We actually have like purpose-built tools that kind of do each of these phases. And the same thing happens when you're doing self-hosted deployments, right?

You need to think about how do you do licensing, how do you do air gapping, how do you do testing? Like how do you do security?

All of these things are very different in that commercial software distribution world.

And you can either build all that tooling yourself, which like GitLab and GitHub have 40 people that are on the distribution team and they're really focused on how do they package their application and make it installable and keep customers running, and have fully licensed and easy to update and manage and monitor, and support, or you can use a tool like Replicated.

Benjie: Right. And so, I mean, one of the reasons why we're finally getting around to doing this episode is because you guys have some really interesting open source stuff coming up.

Can we talk about that? Can we hear about what the latest and greatest is?

Grant: Yeah. So, this is a really interesting product that we're launching.

It's actually a new kind of total new line of business, new brand for Replicated. It's called SecureBuild.

And so, listeners can go to securebuild.com and find out what it is exactly.

But the whole concept is that we are partnering with open source projects to provide zero CVE images of their project. Each one of these projects, for example, we have like Weaviate, TimescaleDB, Coder, Rclone, they all get a landing page that's specific to their project and they reference that landing page on their docs in their registry for their community who care a lot about security.

And they want to see the image go from a hundred CVEs to zero. Those community members can now click through and purchase a zero CVE version of that project with a six-day SLA for critical and 13-day for the other CVEs.

And we will be building these basically by mapping the full dependency tree. So, all of these projects have dependencies.

We're basing these off of minimal images but they still have some dependencies when one of those dependencies publishes a CVE.

We rebuild the entire build chain in order to create these images that have all the fixed CVEs addressed. And we keep an SLA on that.

We handle all the commercial terms around this. And what makes it really unique and special is that we're partnering with these open source projects and giving them 70% of the direct subscription revenue to their project back to the maintainers.

So, Weaviate, Timescale, you want to buy one of these SecureBuild images.

Those people that actually built the project are going to be the ones benefiting the most from it. And what we think is that actually has the opportunity to create a very like sustainable open source world.

One that is focused on security, but we'll probably talk about it. But I think you had the founder of Chainguard on this podcast a couple years back and they've been in this market, kind of developing this market for the last two years.

So, they have Chainguard images, which is what has really propelled their business to about, they're going to do 100 million of ARR this year by basically selling secure open source.

And so, our perspective was why not do something very similar but leverage the open source community as our channel partner so they can share these builds out and then use as an opportunity to give back to those open source projects because we all benefit from the work that they do. And if enterprises are really excited about buying these zero CVE images, let's have it benefit both the creators who made these things as well as the companies that do the building.

Benjie: Okay. So that's kind of big news. So, this is my layman's understanding.

Basically as a corporation, I want to use Postgres in my enterprise environment and if I just pull from Docker Hub Postgres 17, God knows what that's going to be from a few security angles, but specifically the CVE, it could be just an old version of Ubuntu or whatever in the Docker file.

And so, there might be all these CVEs, let alone in the dependency chain like SSL or open SSH, all that kind of stuff.

So you guys, I can pull an image from securebuild.com, is that right, SecureBuild?

Grant: Yep.

Benjie: I can pull an image to securebuild.com.

That would be Postgres 17, but it's SecureBuild one and I have basically, I can sleep at night knowing like, you guys have scanned this for all the CVEs, it's a minimal build of that image, and it's all like super and you got the SLAs and all the enterprisey stuff, and obviously you guys, Replicated is pretty good at enterprise.

So, it's a lot of confidence there. And then to boot, it's the app store model where you're actually giving the majority of the revenue from that back to the open source maintainers themselves, is it the maintainers or as an open source project... do I have to reach out to securebuild.com and sign up or are you guys going to just do this for the whole open source world or how's that going to work?

Grant: Yeah, so right now you need to become an official partner.

So, basically if you're an open source maintainer and you have a project in a distributed container, that's a distributed image, we want to talk to you.

And so, just go to securebuild.com, sign up. We'd love to have a conversation and hopefully make you a partner.

There's not a lot of requirements, we're just asking that, hey, if you become a partner, you inform your community.

We also want to get embargo access. So if you ever find like a critical CVE in your code directly that you're going to like tell some of your other distros like, "hey, there's a... We're fixing this vulnerability. Make sure that when it's out you have the patch ready."

We want to be included on that list. But that's about it. Validate that your release works once you have it, tell your community about it and keep shipping great open source.

Benjie: That's pretty cool.

Marc, to shift the nerd meter back over to nerd a little bit, can you tell us a little bit about the technical challenges and like what's happening underneath the hood?

Marc: Yeah, I mean like Grant mentioned, we had to build the entire dependency tree, right?

TimescaleDB is not just like a single go binary that's statically compiled. That has a lot of other dependencies and everything, they have to be in there at build time and at runtime.

So, mapping all that out and then building it, we're actually kind of taking advantage of some of Chainguard's open source work that they've done.

They created Wolfi as an operating system and Milan is a build tool.

So we're using that which is basically a glibc version of an alpine, minimal operating system, APK-based. So we build them all, host an APK repository, and then create definitions of what these OCI images look like, what Postgres 17, 17.5, 16 look like.

because we want to keep the old major versions as long as they're still not past end of life. We build them, we generate an SBOM for them, publish that.

We scan the image pretty regularly and also we scan the canonical image, the image that's like in Postgres, like the Docker Hub library image for Postgres.

We identify what those canonical images are, we scan it, we scan ours, and you can see the differences between the two.

And then when any package gets updated, we're not going in and saying, oh, there's this vulnerability.

We need to go address the code in open SLL or whatever that is to address the vulnerability.

We're waiting for that package to get a new release because it has the vulnerability addressed in it, but recompiling LibSL or OpenL app, whatever it is doesn't do enough for us.

And so, we have maintained, we know what depends on that, what depends on that all the way down.

And so, ultimately if something, not even a direct dependency, but like multiple layers up the tree get rebuilt, Postgres 17.5 gets rebuilt and a new SBOM and security scan and everything gets published on the site, so you should be able to pull that version then.

Benjie: So, if a CVE is not fixed or something, I won't be able to get it off of...

Marc: Yeah, that'll still have a... So the way it works is-

Benjie: Which is good. It's a good thing obviously, but yeah.

Marc: Yeah, the way it kind of works in practice is we say it's CVE-free.

Like when a CVE gets disclosed, if there's no fix upstream that CVE is going to be in the image that we're distributing to.

But what we can do is have this SLA on once that release, once the fix for that CVE is published, we can make sure it gets into every image that you're using and like upstream open source images that are sitting on Docker Hub may or may not do that.

They all have different SLAs. They might not even know about a vulnerability.

Benjie: I don't know if they have SLAs actually.

Grant: They don't have SLAs. Yeah.

Marc: So like, yeah, that's the advantage that we can give.

Benjie: I mean that's a pretty cool product.

I really like this app store model where you're trying to kind of help the open source community monetize these things 'cause you know, there's a lot of talk these days about with what HashiCorp did and all that stuff.

There's a lot of talk about like what's the future of open source? So this seems like it could be a really good, a really good way to monetize.

Grant: Yeah. We think it's a really powerful way for these projects to monetize.

I mean obviously again, Chainguard's going to do 100 million this year on these images. Docker's getting into it, Wiz is getting into it.

I think you're going to see more and more enterprises are really buying this as a solution. And we think, hey, the best people to validate that these images are the right ones. And to keep us in the loop on any vulnerabilities in their project directly are the maintainers. So let's really, let's partner with them, let's build that in.

And they're also closest to their community. So, they can share these out.

They can make this part of hey, here's how we work with our community when they have questions around CVEs.

Our position is that the images that these projects publish on Docker Hub should sort of be like more developer-friendly images, right?

Those should be kind of fatter images that have bash, maybe they're based off of a larger OS so that you can get in there and like actually kind of like kick the tires a little bit.

But then the SecureBuild images should be kind of production-ready, production great.

So they should rip out everything else possible and then keep that SLA on removing as many of these CVEs as they can instantly.

And the other angle that we think is important to take from like a how do you monetize without changing the license is actually inspired by what Linkerd did.

So, Linkerd actually stopped producing a stable release. They only produce edge releases.

So if you want to use Linkerd and you want to use the open source, you're just going to get an edge release.

And so, it's kind of always just like built almost nightly, but it's kind of like a fairly frequent build of Linkerd.

Whereas, the vendor ecosystem, which is really buoyant, offers buoyant enterprise Linkerd and those customers get a stable release and they get some assurances around security, and they get some assurances around support and things.

And so, we are trying to build the platform on which maybe the next Linkerd says, "Hey, instead of building all this stuff ourselves, we're going to partner with SecureBuild and say SecureBuild is actually our secure and stable release."

So we're we're going to do this with SchemaHero in a couple weeks, which is SchemaHero is a project that we started that we donated to CNCF.

We're the core maintainers on it. And our intention is to stop creating a stable public release.

And instead, we are going to say, "Hey, if you want the stable release, you want an image for that, it's actually available alongside of our SecureBuild."

So, you'll be able to go to securebuild.com and subscribe to the SchemaHero image and that'll be 500 bucks a month.

And that's going to get you the SLA around security and the stability that you're looking for.

And we would love to see more open source projects take that exact same approach because we think it will accrue more of the value upstream to maintainers.

And so, instead of the cloud providers and the Chainguards of the world who are going to create their own builds of these things, we think this is a way to really drive more value to maintainers.

And so, we're putting that out there and we're going to lead the way with our CNCF project that we're maintainers on.

And we'd hope to talk to other folks that want to do the same thing. And we've already had some really great conversations.

Obviously, we've only been doing this for a couple months and we already have in stealth and we already have 10 open source projects that are launch partners, right?

And so, over 200,000 GitHub stars are represented in those launch partners.

So we think we've really found a nerve that is going to drive open source maintainers to partner with us and to actually promote these SecureBuilds to their community.

Benjie: Okay. That's super interesting. What's SchemaHero, just out of curiosity?

I know what SchemaHero is, but Marc you want to tell us what SchemaHero is real quick?

Marc: Yeah. I mean, Grant mentioned it, it's just an open source project that we created and it's a CNCF sandbox project now.

It's declarative schema migrations for different databases.

So instead of writing liquid base or flyaway or whatever migration files, you just define the way you want your schema to look in the database and the SchemaHero calculates what those migrations should look like at deploy time.

Benjie: Right and so this is a CNCF project and now I can have a CVE free with confidence copy of it if I'm using securebuild.com.

And like you said, there's going to be 10 other projects that you've already signed up for this.

If I am a open source project listening to this, probably on the Kubelist side, not the EnterpriseReady side, how do I sign up? How do I sign up for this? Just securebuild.com?

Grant: Yeah, securebuild.com, click partner and fill out a little form and we'll get in touch, you'll probably talk to me and Marc and we'll figure out how we can, maybe we already have a build of your project coming.

I mean we're able to leverage most of the Wolfi OS library, which has about a thousand different images in it.

So, we're starting to kind of build that entire catalog and we should have that out soon.

But we'd love to get the community really involved and make sure that maintainers who want to get paid, get paid.

Benjie: Okay. That's super cool.

Marc, can we maybe talk about what Wolfi is in a little nerd for like 45 seconds? 'Cause I know that's a super interesting one.

Marc: Yeah. Wolfi is an operating system Chainguard released. That's the core of their base images.

One of the challenges with Alpine, right? A lot of us went to Alpine container images because they were small and minimal, and then you had to adopt a whole bunch of different tooling like APK as a repository instead of APT or YUM.

But one of the biggest challenges with Alpine is that it's not glibc-based, which meant that like you have to recompile special versions of your application to make them work in Alpine.

And generally speaking, most like most go apps would work, but like not every app was really trivial to be able to do.

And so, they basically, Chainguard created this as a separate project that they based a lot of their stuff on too.

And it's a glibc minimal operating system that uses APK as a package manager.

Benjie: So this is a way to like handle the builds for all these other things.

Marc: Yeah, Melange just like a tool that they've open sourced that's like building tool.

You're not going to run this on your desktop or anything like this. It's definitely meant to run in kind of like these shell list containers running in your production environment.

It's definitely hardened and meant to be that way. But it's basically just a minimal version of Linux that is compatible with most builds.

Like we've gone through the process of onboarding some folks into SecureBuild that didn't have a Wolfi compatible version of their package build and it was pretty straightforward.

If you have a make file then you can kind of build on Linux, it's probably likely to work and like it works on ARM and x86-64.

Benjie: Yeah, I was going to ask, so, I can have ARM and x86 images with SecureBuild?

Marc: Yeah, most of the images as long as the application supports it and right now the ones that we have in the launch partner do, but like they're multi-architecture images across the board.

Benjie: Is SecureBuild really something for me as a local developer or as like a local dev or not as much, it's more for like the enterprise world?

Marc: Yeah, it's more for like the enterprises.

I think like one of the other advantages, we talk about SchemaHero as an example, shipping this CVE-free version and obviously the advantages there that are, I as a developer, an open source maintainer of SchemaHero, I don't need to worry about maintaining and responding to CVEs and having this minimal aversion.

But it also lets me really stop trying to balance between minimal but like a nice developer.

Like I'm a developer, I want to learn SchemaHero and pull the image, but it's like I wish I had curl and git and bash and everything in it.

And so, you end up kind of being a little bit in one foot in both sides of a developer-friendly container that you can use to debug stuff, but also a minimal one.

So this actually just splits that and says, look, pull the developer-friendly fatter container image down to your local dev environment when you're learning, when you're onboarding with the tool, when you want to debug something.

But one of the things that we worked really, really hard on is trying to make sure that the SecureBuild images are drop-in replacements.

Like we've done stuff to like, we've wrote a lot of tooling to make sure the entry point and the default ARGs and everything like this in these images work the same as the canonical one does.

So, if it works locally, obviously, test everything but if it works locally, you should have high confidence it's going to also swap that out with a SecureBuild image and it's also going to work.

Benjie: How did you, the tooling underneath that, I think I know the answer, but how are you doing all these concurrent builds and doing all that stuff?

Marc: So, one part of Replicated, Grant mentioned it earlier that we built is this thing called compatibility matrix, which allows you to spin up ephemeral VMs and Kubernetes clusters really, really quickly to test your application prior to shipping.

So we had all this essentially like a hypervisor that could create x86 and ARM builds or VMs on the fly using Firecracker. And so, we just leverage that.

And so, whenever we're trying to run a new build or build a whole part of the tree over again because the dependency high up was fixed, we just spin up a whole bunch of Firecracker VMs on our own compatibility matrix, which is in very lockdown kind of tight controlled environment that we've, this is a GA product that Replicated's had for a while and we're able to use that to actually run all these builds.

We're not like reusing any of the infrastructure or anything. Every time we build a piece of software on one architecture, one version, it's a brand new VM and it gets thrown away afterwards.

Benjie: So it's a fresh Firecracker, if you will.

Marc: Yeah, exactly.

Benjie: So I mean I think that that's kind of interesting.

Obviously, I've been a co-host with you for a while and I have, I'm a Replicated fan, so I know a little bit about this.

But I think it's really cool that some of the, that grid product you're talking about, which obviously you use for your, maybe not obviously, but to me it's obvious, for your customers to test these different adverse environments to install their application on.

You're now repurposing that for the SecureBuild product, right?

Marc: Yep, that's exactly it. And I think we're able to create the VMs on the fly, we're able to...

You know, we will get to the place where we're actually like using some of that same, that our, like our core product is evolving to start doing some hardened STIG and different types of testing on these and we're going to like, when that's available, we'll apply it into SecureBuild also so that we can test the images and all those different environments.

Like it is something that we intend to keep pace with Replicated. As Replicated introduces support for something new, we will make sure the SecureBuild also has support for that.

Benjie: So this is a first class product launch that we're talking about here.

Grant: This is a really big investment for us for a couple of reasons, right?

I think one, we talked about the commercial software distribution lifecycle and what we have seen is that our customers, right, so ISVs and open core companies are often required to address all these CVEs in order to deliver into secure environments.

So if you're delivering into FedRAMP environments or into large banks, they're going to scan your images and they're going to push back on CVEs.

And so, by being able to build and deliver dependencies that actually have those addressed, it's just a core need for our customer base. I think that's what makes part of this so compelling for us.

Marc's talked about some of the technology. That's just one of the components, right? We also have all this registry code that we've been running at Replicated that separates out what images and Helm charts can get delivered to different customers on different timelines with expiration and delivering different entitlements.

And so, we've had that core tech for a while. Combine that with compatibility matrix, combine that with our ideal customer profile being one that both needs to be able to ship zero CVE software because it's just required by their customers.

But also almost half of our customers at Replicated are already open source and open core companies, right? So, they have products out in the open source community that people are downloading and running.

And so, we think we'll be able to partner with them, we think we'll be able to help them ship zero CVE commercial products and then expand our reach to these open source projects who maybe aren't really monetizing very well today.

And this is going to be kind of a turnkey enterprise offering that they're going to be able to offer that kind of on the low end, right, at maybe like a thousand bucks a month.

But it should be something that has pretty broad appeal and click through terms that their customers can just buy with and there's no support contracts, nothing else required.

You know, we already have some of our partners who are asking to say, "Hey, we want to have an add-on to put our support contract on this, right?"

So, maybe our image is 500 bucks a month, but you can buy support for another thousand or you can buy some private images for another thousand on top of that and you can get kind of the enterprise package all the way through this.

So, we're really excited about what we're going to be able to do with this. You know, I think the foundation of security and reliability together is where Replicated is really going to shine here.

And I think it's just such an obvious area for us to enter into and we'll get into the story a little bit later. We've raised a lot of money and I think this is a really important area for us to invest that in.

Benjie: Sounds great. So yeah, I mean, let's talk about the rest. I mean, I've been excited to get Replicated on here for a long time.

So, you just brought it up, you talk about raising money and kind of the story of Replicated as a business.

Do you have any learnings, any lessons?

I'm sure you have a thousand, but like anything interesting that has happened in the last, let's say two years, that has changed a lot of things for you guys?

Grant: Yeah, and we'll get into a lot of them and we might go back a little longer than two years, maybe since 2021.

In '21 we raised a series C of $50 million. This is on the heels of a series B in 2020. And so, I think within from 2020, like kind of we raised the series B maybe like call that August or September of 2020 until like basically the end of '21.

We went from about 20 something people to 135. So rapid growth, rapid rapid growth. Raised tons of money, we were scaling it up. The business was growing really well. We were doubling year over year, but we made a couple of mistakes.

Number one, we let our go-to market team just hire way out of sync with our engineering team.

We were really packing on the people in go-to market. So we had 80 folks in go-to market and only 54 in the rest of the company.

And we had kind of said we were going to scale that way in order to like add capacity so that this is a concept that like, when you're hiring sellers and marketing people, it's all about how much capacity and throughput do you have as an organization.

It sort of assumes that you have like an unlimited amount of market and opportunity.

Benjie: Right.

Grant: And we just didn't.

So, what we had built in KOTS and curl and troubleshoot, like we launched this at the end of '19, it really had what we thought was product market fit, what I think turned out to be a little bit more like message market fit.

And even then, that message eventually started to really like, not land as well, but what we were selling was distribute your Kubernetes application into customers of all different types, meet your customer where they are, and then we were using huge amounts of cash in order to get new customers.

And so, it was a very inefficient business. And while we were scaling up the business, I think the underlying market changed and we went from something that was like packaging, it could be customized, it could be just give operators to everything became Helm charts.

And so, Helm really won out and our product just wasn't like that great with Helm. Like you could put a Helm chart in, but we would still deploy it with our tooling.

Kind of like, almost like an Argo kind of deployment where it didn't support all of the different Helm functionality, hooks, and all these kind of things.

And it added more complexity and didn't solve enough problems. You know, I think the free money of 2021, that era where customers were just buying and everything was working, as that kind of got the brake slammed on it at the start of '22, we realized that the customers weren't getting that successful.

We'd oversold many of our customers, both in terms of how much they were contractually obligated to pay us versus the value that we were providing. As well as how we were telling everyone this was the easy button for on-prem software. And unfortunately, there just isn't an easy button for self-hosted on-prem software. It's a very hard problem. And so, we had to reset expectations.

We didn't have much data around who was using what so we had to get the data.

We were obviously bloated from a company perspective, so we had to let, we basically get down to about 35 people I think at our low, and today we're on 42.

But we had to let a ton of people go. We turned over most of our exec team.

We went through all the challenges that you go through when you're trying to like steer the ship a different direction and change everything dramatically.

Benjie: I think I saw this on an episode of "Silicon Valley," I'm pretty sure.

Grant: Yeah, yeah. It's pretty close.

Benjie: Yeah, are you quoting a TV show or are you actually telling me what happened at Replicated?

Grant: Yeah, this is, I think maybe in the, like, the follow up to what happened in "Silicon Valley," when Richard's complaining and you're kind of telling the camera, "Oh, here's how everything went wrong."

A lot of stuff went wrong.

Benjie: Spoiler alert. Sorry, sorry. I should have said spoiler alert before I made that joke.

Grant: Yeah.

Benjie: So I mean, like we've seen, I've seen it personally funded company Shipyard but other friends also just like the board's like "hire sales, hire marketing. It's go, go, go gas, gas, gas."

And then you wake up and you have, you said 135 employees?

Grant: Yeah.

Benjie: And then you're like, that's not going to work. And then cut to now you're kind of, it sounds like you guys are getting rights.

You feel, obviously you don't... The whole point is that we don't know hindsight 2020, but it feels like from just knowing you for years and just talking to you, it feels like you guys feel like you're kind of right-sized and you're kind of starting to focus on a lot of the product that folks want and need.

And like you said, the challenge around a magic button for something that there's just no magic button for...

Well, Sam Altman will give us a magic button for it, like in six months, but for right now there's no magic button for on-prem software.

It sounds like you guys have learned a lot from that.

Grant: Yeah, I mean, it's been the more challenging experiences.

You know, I look at where we were, I mean, I'm actually much happier now than I was when I was running the 135-person company.

At that point I felt like I'd lost control of the company.

Things were a little bit weird back in '21. A lot of people were kind of focused on workplace activism.

And so, that was a really important topic and people wanted to get and work at a place that really believed all their same social beliefs.

And those are conflicting and not everyone believes the same things.

And so, it was a difficult company to run and ultimately we just weren't creating enough value for customers. And so, that's what we came back to. We got the data, we understood what was happening with customers.

A third of our customers weren't really using our product. We'd oversold too many of them.

We kind of made a commitment to like, not just like fire every customer and start from scratch. We're like, we're going to figure this out.

We're going to try to make the transition happen and we're going to build things that really make this process better so that our customers can offer world class, self-hosted software.

And so, that's things like the distribution lifecycle that was the vision. Hey, we need to deliver on this.

So we introduced compatibility matrix testing in order to, if you get your testing right, you can move on to the next phase, right?

So then it was, we need to be able to do reporting. So we introduced a lot of reporting tooling and an SDK to distribute your Helm chart.

And actually just a couple weeks ago we launched this new enterprise portal, which is a fully white labeled end customer experience for doing installs and updates and getting support bundles, and seeing all the security artifacts that you package with your application.

So, all these things kind of have become a very complementary, there's a lot of really good kind of overlap between what we're doing.

We're making our customers much more successful. We have, not because they're growing, but because we're actually creating products that really help them deliver this way.

So, I think the future looks much better at Replicated, but it was a real challenge for a long time there.

And at our peak we were burning almost 2.5 million a month, you know? And so, that's just unsustainable.

Even you raised $85 million, you can't do that for very long. But at that point we thought, oh, we're going to raise 100 million after this.

So, we cut the burn down dramatically. We got near break even. We tried to figure out what we're going to do next.

And now the key thing is investing in SecureBuild, investing in the core products of Replicated, and helping software vendors deliver amazing self-hosted software and focusing on the supply chain security side.

Because ultimately Replicated is a core part of supply chain security for a lot of commercial software.

Benjie: Yeah, what's the stat you guys have in your site? How many Fortune 100 companies?

Grant: Yeah.

It's generally around like 60, 70% of the Fortune 100 are deploying applications that are delivered through Replicated.

Benjie: I always think that that stat's super impressive, also 'cause I can do the math on the Fortune, that's 60 or 70 companies that are using it. So I appreciate the ease of math there.

Grant: Yeah.

Benjie: Thank you for making me feel so smart on your homepage.

Okay, cool. I mean, I really feel like you guys have been through it and I'm excited about the SecureBuild. I'm also excited about the other stuff.

I personally am waiting, I want to use your grid product personally, well, for Shipyard, but I have plans around that at some point.

So, I really like where you're going with all that stuff. Is there anything else that we haven't covered from the Replicated story side that you want to touch on?

I feel like we hit most of it, but in case there's anything-

Grant: I mean, the other part that I think you mentioned it earlier, but I think it's just foundational in this day and age is AI, right?

And I think we actually have a pretty interesting story around this because we were adopting Copilot.

Marc was very early to all these tools, right? What was the next one? Supermaven, Marc, right?

Marc: Yeah. And a little bit of Cursor here and there, but like, we were just like I think, as an engineer, if it's effective for you, if it's useful, use it.

And we'd see kind of like various adoption across the org. And then like, I think we realized that there's a lot of different things that kind of came together.

One was when you really, really dig into these tools and you start really using Cursor really well, not just like using, auto complete's really good, but when you actually start using it better, but then you also start using tools like Bolt and v0 to do some product discovery and mockups.

And instead of sending kind of really bad and hard to understand wire frames internally, you're actually sending clickable product demos that you can actually share with a customer and get feedback before we build them.

And then we adopted Devin and have Devin doing a lot of background tasks on various parts of the stack.

And eventually a few months ago, we just kind of pulled the entire engineering team together and actually it was a little bit more than the engineering team, we pulled in product managers, we pulled in some other folks and just did an AI week where we're like, everything we do this week is going to be written with AI. Everybody's going to get really good at using these tools, figure out where it's good, where it's bad, how to use them.

Kind of give you an opportunity to force you to take a pause and learn how to use these tools to do the job that you're actually trying to do.

And I think since then, I mean we've had a lot of usage, a lot of adoption of them.

And I think we're at a point now, look, it's not like 100% of the code written at Replicated is being generated by AI, but every developer has access to all the tools and is getting pretty effective at using them and using different models.

Like last week, I think there was a huge Google Cloud outage, which brought down Anthropic and Gemini at the time, and it was noticeable because everybody was like, wait, I got to figure out how to write code by hand again.

Like you just, you realize how much you're relying on these things and how much more efficient you are as an engineer.

Benjie: So, okay, actually just to again, nerd a little here, on the Cursor front, what is the right way to use Cursor?

I've heard a lot of things these days. So YOLO mode, you still don't mess with YOLO mode, do you? Or do you use it?

Marc: No, everybody's in agent mode, right? You like-

Benjie: So no YOLO mode, but agent mode, is that correct?

Marc: Agent mode, right.

Benjie: Is that the same thing now? Maybe it's the same.

Marc: I think it is, yeah. And it's like the default now too, but like-

Grant: We don't allow it to RMRF anything though, you know? We keep a couple of commands away from it.

Benjie: Yeah. but I think like it's, I've heard stories of it like committing stuff and then pipelines like triggering.

Grant: We haven't seen anything too crazy. You know, our position is you have to lean into as many of these tools.

Ultimately, I think Marc told the story, but like, he was just on the cutting edge of all these AI tools as they were emerging, right?

And it was about, I don't know almost a year ago when like they just started to all really click and it was clear that it was like, okay, this stuff is working.

We need to use it more. Supermaven got acquired by Cursor. So like we were like kind of forced in using Cursor, but it was fine.

Supermaven was was quite good too. And I started using it. So, this is Benjie, I think you'll really love this, right?

Like a year ago this time, I would prototype from a product perspective and I would use Google Slides.

And I would draw little boxes and I would create each page as a new slide.

And that's how I would communicate the vision of what I wanted this to build.

And then about, I don't know, six to nine months ago, I got my hands on Bolt and I said, you know what, instead of using a Google Slide, I'm going to describe what I want to do here in Bolt.

So I had it build a single page. And then I had to build a couple pages from that page.

And then eventually I basically ended up with, like, I'll call it like an AI like digital mock of my entire Replicated application.

Except this version had all the new features and things that I wanted to build kind of already prototyped into the UI.

So using mock data as the back-end, right, instead of like doing front-end, back-end, I was basically just doing a front-end mock with mock data files.

And being able to prototype that way, and to Marc's point, giving your team something that they can see, so when you tell them you're going to build this amazing experience, now they can see it, they can understand it, you can communicate it so much better, right?

Then you take it to customers and you have seven features or nine features in this thing, and you key in on... I show this to 20 customers, what are the three features that everybody lights up on, right?

So now all of a sudden I'm really using this inspired methodology where I'm prototyping, I'm showing stuff to customers, I'm getting the team on board, and now we're building.

Benjie: Okay, so what you're telling me is that Grant is now a vibe coder.

Marc: Well it's like, think of it this way. It's prototyping sharing with customers but it's more than that.

It's not like, oh yeah, this prototype really worked, give it to an engineer and they got to go zero to one on it.

No, because it turns out Bolt is writing React components, right? Like three has mock data and it's not, we're not deploying that code into our production environment.

But I know like for SecureBuild and I've done this on other projects where I've worked with Grant too, where I'll download that from there and I have the zip file, I'll drag it into Cursor, and I'm like, okay, here's a bunch of React components. Modify them to fit the shape of this project. Remove the mock data, call in the server actions or the APIs or whatever it is that we actually have. And like-

Benjie: And that works.

Marc: Yeah, it works really, really good.

Benjie: So, basically really the product development side of, I mean I just I'm always scared of Grant touching too many things 'cause you know, I'm scared of him, but-

Grant: As you should be.

Benjie: It sounds like Grant, I mean, it makes perfect sense to me. Honestly, Grant was always slightly too dangerous with knowing stuff.

And so, now he actually has, these tools are actually enabling him to bridge the gap.

And so, you're not like designing something in Google Slides then getting someone to do in Figma and then like someone to like do some React that's not right.

Like you're skipping like seven steps and getting straight to product.

Grant: Exactly.

Benjie: And the iteration cycles, that's right, huge, right?

Marc: It's so much faster. It's created an interesting challenge where you're constantly blocked on code review though.

I feel like code review becomes a huge bottleneck because like we can just produce code so much faster and folks who weren't producing code before were, but we still want code review, a second set of human eyes on everything.

Sure we use some AI tools to assist with code review, but it's not okay just to, for Grant to like vibe code some code, send it to an AI code reviewer, and then deploy it to prod.

We're not doing that. Anybody's doing that.

Grant: Well, let me tell you what the rest of the story, Benjie.

So, I was using Bolt initially and I was creating all these mocks and I realized I had mocked up a bunch things, but now I needed it to get built.

And so I told Marc, I said, "Look, I want the development environments. I want to start to use these."

And so, I got the development environments and I made some changes to our internal admin tool, right? Just some front-end changes, some React stuff.

I said, okay, I got the workflow pretty good. Let me make a change to the front-end of our like core web app, the vendor portal.

And I made some of those changes. Again, code review by the team, got some feedback, made some adjustments, got that process going.

And there was about a two or three-month period where I became one of our most prolific developers.

And I did this for a couple reasons, right? I wanted to be able to understand the process of what it's like to work at Replicated as an engineer.

I taught myself how to program 15 years ago. I was a shitty engineer, right?

I taught myself PHP and some SQL and I would just enough to prototype things, but I'd never contributed a line of production code to Replicated until three months ago.

And so, with the help of Cursor and Windsurf and these tools and having our development environments running, I was able to say, okay, I've got the dev environment.

I know what I want the product experience to feel like and I want it to do, so, I can read the code that comes through and understand what's happening.

But I just couldn't author that code by hand and create that syntax. But I can read it all. I read everything I write.

So, I think the difference between a vibe coder and maybe someone who's like an AI-assisted programmer is I'm reading all the code and when I see something that looks off, which I have caught many things that are off, right?

There's some funny stories in there, but I'm reading it all. And I had so many interesting insights as a CEO who was programming.

The first of which was our schedules were all off because we were allowing the managers to set the meetings. ICs, who are our engineers, their job is not to show up to meetings. That's not why I pay them. I pay our engineers to develop great products and to ship things that customers are going to love. And if that means you don't show up to a meeting because you're in flow and you're trying to get something done, that's totally fine.

So I had to change our engineering culture to allow that to happen. And say, we canceled all of our weekly meetings.

We said we're no longer going to have any weekly meetings, our meetings are at most every other week to increase the amount of focus time our engineers get.

The way that I kind of realized that, like I work a lot and Marc works and a lot of our best engineers work, is that they have this mentality that I call get it done today, right?

Which means you wake up in the morning, you open up your development environment, your editor, and you look at and you say, what do I want to get done today?

And you've kind of chunked something pretty big that you're going to try to do.

And you start and you get it done and you ship a PR by the end of your day and maybe you get a bunch done before dinner, you go have dinner, you come back, and you do a little bit more.

The next day is all about getting that PR into production and you're working with other folks, you're reviewing their PRs, you're doing that work, but now you get that new PR into production and the next day is another get it done today day.

So you get to tackle maybe three major things every week if you work this way. But we had to change how we work in order to make that possible.

Because if you have a one-on-one or a team meeting in the middle of that workflow, that just doesn't work. So we need to make sure that we structure our calendars around giving our engineers, our core engineers the most productive time possible. And I wouldn't have understood that had I not been working as an engineer on this team for a couple months.

Benjie: I refuse to call you an engineer, but that is an inspiring story.

Grant: I mean, you can call me whatever you want, but that's what I... You look at my Cursor usage, you look at my commits, you look at my PRs, and again, we have an amazing team that was reviewing every PR, that was giving me feedback.

Benjie: And you learned a lot from this, obviously.

Grant: I learned a ton, I was building Go handlers, I was doing the whole thing.

And so, I was doing back-end and front-end by the end of all this, right?

I could do anything that like, again, I'm not going to do what Marc built with this SecureBuild factory and all of the dependency graph mapping and everything else, but like to build a standard web application to use, to build a migration in SchemaHero, to add a new table, to add some new columns, whatever else I could do that without a problem.

To add some ghost services, to handle whatever we're doing. No big deal. And that's a world away from where I was before.

The nerd here, I'll bring it to a little bit nerdier. So I was reading a lot of fantasy at the time, epic fantasy.

So I was reading, I had just finished "Name of the Wind" and I was reading some Brandon Sanderson "Mistborn."

And if you haven't read "Mistborn," one of the things that happens in this book is one of the main characters is not able to do like the magic that the rest, the main characters can do.

He's not Mistborn. And at some point he becomes Mistborn.

And so, I felt like I had been in this world where I couldn't actually do the magic system that Marc and all of our engineers could do.

So like, the programming as magic. And all of a sudden I was codeborn.

I was able to write great code that could get into production and build things and really create something magical for our customers.

And that was this kind of interesting parallel that I was able to draw because of what these AI tools, the powers they've given me.

Benjie: Do you have a name for that?

Grant: Yeah, I called it codeborn.

Benjie: You call it codeborn. So Grant is codeborn. I think that, putting on my EnterpriseReady hat for a second.

I think that for anybody, especially in the C-suite side here, as someone that straddles the engineering and CEO stuff myself, the more you get hands on in this world and this ecosystem, the more you're going to understand what you should be doing.

And it pains me to say how great a job, it sounds like Grant's doing over there and understand that and getting rid of these meetings, stuff like that, that's right where it's at.

At Shipyard we use these tools as well. I'm really playing with Claude Code right now personally.

That's my thing. I don't know. Marc, have you played with Claude Code yet?

Marc: A lot, yeah, for sure. It's pretty popular on the team too.

Benjie: Yeah. I don't know, being a CLI think is kind of cool.

Anyways, the point is is that Grant being the CEO of Replicated and actually, for frankly knowing what a go module is, is pretty impressive to get there and to do that stuff.

So, do you have any like raw numbers on productivity results since you started kind of changing this fewer meetings stuff or every other week meeting thing and the get it done today mentality that you were talking about?

Grant: You know, it's so hard to really measure engineering productivity, right?

I think we look at PRs, look at things. I mean, I think it's about... I think there's a feeling which is like, are we shipping stuff that our customers really appreciate?

NPS has moved up a couple of points, right? I think it's up four or five points, which I think is a good indicator of like, we're building the right things.

Marc and I always say engineers want to be on teams that ship great software. They want to be moving things forward. They don't want to be constantly just fighting fires and constantly just in meetings. They want to build stuff.

And you want to get, you want to build stuff that customers use. And so, that's what we're doing. And yeah, you have to make a lot of changes.

We made every, and Marc mentioned earlier, we made all of our PMs, all of our EMs, they all got on these tools, they all made PRs because I always liken it, if you're an EM and you're not doing development daily, but your team, like, and you haven't programmed in 10 years, this is like you were building a carriage and now Ford has rolled out the Model T and he's got the assembly line, and you need to go figure out how this new process works and what's new stuff that's being built.

And so, I think every engineering manager, every product manager has to get so deep into these tools in order to stay relevant in this new world.

And so, I put some other CEOing things on hold in order to do that, in order to get really deep in all this and kind of understand what the opportunities were and what the challenges were.

Marc: And to be clear, it's not always just about like, oh, we can move faster.

There's a lot of stuff that might not be the top priority. Like I'll give an example.

We ship a CLI and over the years as we built it, it's become a little bit inconsistent with the way the flags work. Probably pretty common, right?

Never high enough of a priority to go do, it's a little annoyance and it introduces a little more friction when somebody's signing up and trying to use the product.

Benjie: Dash H or Dash help like...

Marc: Yeah, like this flag, that flag. There's like inconsistent.

And so, what we're able to do though is just to describe that problem to Devin, come back in an hour or two, and have a PR that's backwards compatible that fixes that.

So, we're able to like put the polish on stuff that we weren't able to really do before.

Pay attention to some of the details that maybe we were in a hurry to get the first version out and then we didn't come back and like make that modal look a little better or that UI or that CLI work a little better, and able just to like, anybody can do that now.

And we don't have to go say, "Hey, that's what we're going to do for this sprint."

I'm not going to ship any functionality. We're going to go clean that up.

Which we probably should have done, but now we're able to kind of do both at the same time.

Benjie: Time is of the essence in this environment. That's just some pretty good insights I think. Have you guys done any code refactoring with it or not yet?

Marc: Yeah, we kind of like, we'll even like talk through it.

Like one of the things that I'll do is I'll just ChatGPT on voice mode, put some headphones in and walk around like describing the architecture that we have right now and like having it come up with better ideas for it, and then dropping it into a marked down doc or a canvas in ChatGPT, feeding that into Claude Code and having it come up with a work plan to be able to go implement it all.

Benjie: Super cool. Yeah, I want to hear more about all this workflow, but I think we're out of time.

So, the big thing in my mind, my big takeaway is securebuild.com. When is that official? When is that coming out?

Grant: I mean, it'll be live when this podcast is going out.

You'll also be able to watch all of our fun AI-generated ads that I've created about 15 different AI ads with Veo 3 to kind of talk all about what SecureBuild does.

They are quite irreverent, a little bit unhinged. Hopefully they don't offend everyone too much. You can be offended a little bit.

Benjie: Yeah, Kubelist is taking a big step back from endorsing those videos on any level.

Securebuild, very proud to promote. But I don't trust a Grant video, an AI-generated Grant video.

Grant: But if you are offended, just let me know on Twitter, just tell me how terrible I am. I'd like to know. It's totally fine. Just tell me, hit me on LinkedIn.

Benjie: You're @elonmusk, right, is your handle?

Grant: I'm just @grantm.

Benjie: Oh, okay.

Grant: Do not send me an email. I don't want to know privately, I want to know publicly. I think it's important to get public recognition for what I've done wrong.

So, if you really hate these commercials, let me know in the comments and on Twitter.

Benjie: Grant can take the heat.

Also think that AI stuff we talked about is super cool, but I feel like the big takeaway is securebuild.com, the journey of Replicated.

And I have a feeling in a few years we're going to come back and do another one of these follow-ups, see how Replicated's doing.

Thanks for letting me moderate and talk through this stuff. Again, been a big fan of Replicated for years and love seeing what you guys do and learning and all the various things that you guys have taught me personally and now you're sharing with everybody.

So, thanks for coming on and doing this, guys, and yeah, good luck with SecureBuild. I look forward to seeing how that goes.

Marc: Yeah, Benji, thanks for having us.