00:20:32 · Will Stewart, Jack
If I was to do this again, I probably would've started being much more public facing earlier on, talking about what we're building. I think you can talk about what you're building much more progressively. For example, on on LinkedIn, I I post product updates on LinkedIn quite frequently, keeps our customers updated and that's generally very very productive. But I think, yeah, to, you know, what we're all trying to do in startups, right, make enterprise value, you've gotta build something robust that's long lasting and that you can build trust over many many months. [00:21:04] S1: The ones where people wait before launching is often like there's a really strong view on. I I I it feels like you are trying to validate that this is a real problem. It was like you believed it in your bones. It's a real problem. [00:21:22] S0: Yeah. I I think that's true because we had experienced ourselves. Like Fred and I were like, why can't we do this? Why can't I deploy a a database in a number of seconds, highly available? Why can't I deploy CICD? Why do I have to meet these, you know, god awful Jenkins pipelines? Why do I have to set up Mesos manually? Why do I have to install this on an e c two node? We thought, well, we could just automate it. Let's let's give it a go. Let's try and do this. And obviously, that's probably naivety. Right? Like we were young. I thought, oh, we can do this. And if we if we knew what we do now, may maybe we would maybe maybe we wouldn't have
00:21:22 · Will Stewart, Jack
[00:21:22] S0: Yeah. I I think that's true because we had experienced ourselves. Like Fred and I were like, why can't we do this? Why can't I deploy a a database in a number of seconds, highly available? Why can't I deploy CICD? Why do I have to meet these, you know, god awful Jenkins pipelines? Why do I have to set up Mesos manually? Why do I have to install this on an e c two node? We thought, well, we could just automate it. Let's let's give it a go. Let's try and do this. And obviously, that's probably naivety. Right? Like we were young. I thought, oh, we can do this. And if we if we knew what we do now, may maybe we would maybe maybe we wouldn't have [00:22:02] S1: done that. But But it sounds like you started with gaming where it was like you were like, no one else is doing this and maybe it's like feels like, you know, maybe it feels like you were like, let's just build like an easier way for anyone to build anything. It's like feels big, but at the beginning it was just gaming, right?
00:22:22 · Will Stewart
[00:22:22] S0: I think, yeah, it was incremental. So we started with the game servers, but a game server is just a Docker container, it's a Docker file. Very quickly, we're like, well, we built this software, this capable platform to build and deploy Docker file. That works for Node. Js, works for Java Spring Boot, works for PHP, works for Rust. Like, okay, well, what's what's MongoDB, what's Redis, what's Postgres? Well, it's a Dockerfile, it's a container. Oh, we could potentially allow people to one click deploy Redis Postgres. And now, in today in Northlink, we have highly available managed offerings of, you know, six to seven different databases that you can run-in one click in your in your VPC, and you can also do that for your microservices, And it's now a sort of a consistent vision since, I'd say, 2019. Our PreC decks and everything we'd written then, interestingly, is exactly the same pretty much of what we say today. And that's very unusual, especially in startups that Yeah. Need to pivot for for for for good reason, or, you know, the market evolves, but nothing really has truly changed. Every single company needs to deploy software. The way people build software is changing right now, quite rightly. But the way people deploy software and run infrastructure has not changed. Yes, Kubernetes is a different orchestrator, but before that we had Mesos. Before that we had number of like Ansible or anything else.
00:23:50 · Jack, Will Stewart
[00:23:50] S1: Yeah. Here's a here's a question I think about a lot because like there's this whole like, you know, the the YC wisdom of like and maybe Lean Startup is like more of the thing where everyone was like testing things, like build it fast, put it out there. There's also these other startups like you guys, like WorkOS, I think. Shout out sponsor. [00:24:12] S0: They We we were a customer. They're great. [00:24:15] S1: Oh, you're actually? Yeah. Okay. Nice. Nice. So there's like this kind of vision from day one where like this is what I'm gonna build and I'm just gonna go build it. So my question is like, if you're solving a problem for yourself and you kind of know there's a problem, how does like customer feedback come into things? Because I think it's a bit different when you're entirely starting off like completely driven by like what people are telling you.
00:24:41 · Will Stewart
[00:24:41] S0: Yep. So clearly we have the, you know, the overarching vision, but we're not always right. You have to know when a customer is telling you and you've got an average. So you don't generally take a specific customer's feedback out like at heart. You've gotta you've gotta sort of understand the rough edges. Right? What what they're saying is true, but there's actually something behind that, which is I actually need a different way of doing something. I need this feature which I don't know how to articulate. Or you have to take the average of maybe five to 10 different opinions, because we're trying to build a horizontal platform. This thing got to be carefully integrated with each other. So like if one customer wants one feature, they may break another feature. So that's not gonna work in North Flank. We have to be very careful and considerate how we take on user feedback. And and generally it's our, you know, world view on this is we want every workload to run on North Flank. If if a user can show us a workload that can't run, we're gonna build features to make it possible. Because you should be able to run everything on North Flank. If you can run it in Kubernetes or on a Linux VM, you should be able to run on North Flank in a great self-service developer experience. That's that's how we approach features. And then I think that's where we're quite unique and like we didn't we didn't quite rightly people were trying to replace Heroku and build, you know, next generation PaaS. I think Northlinks take a very different journey to that. And I think that's that's where the larger opportunity is because 99% of companies do not use PaaS. Right? Most of them need DIY on top of EC two, GCP, or or on prem. So we're we're trying to solve a larger problem, which is how do how do businesses, how do large enterprises build and deploy unlimited number of combinations of software. And that means that you have to take the average of many different people's feedback and then build that in real time. And I think we also complicated it a little bit because we made a rule. Every feature we build has to be available in the UI, API, CLI, and GitOps. So it's a very very unified experience, very the user chooses the weapon of their choice. Right? Yeah. Yeah. They if you love UI, great, you're gonna love Northlink. If you love API, you're gonna love Northlink.
00:27:01 · Will Stewart
And it's the understanding within a company, a product manager doesn't know how to use the CLI. Yeah. The founder may not, but they want to be involved in the release process. DevOps teams love being in GitOps and APIs and CLIs, but sometimes they want to be in the UI. So when we started constructing the platform, it was around that concept, which is unified developer experience across all mediums and unified feature sets so that you could deploy a whole platform. And some people started with just databases or just microservices. Like, well, I can't deploy a mission critical system if it has to talk to another platform with a hundred milliseconds of latency to a database. You have to run everything in the same VPC. So that that's how we approached it, which is our users are all gonna have very very different requirements, but if we can average it and build it consistently across all of these developer experiences, then actually we can keep iterating very very quickly. Mhmm. And we we as a team over since 2019 have not deprecated a single feature. Really? And that that's that's super important because people are they're onboarding and building trust and they're trying to build businesses, and it's our job to do manage deprecation. So for example, we manage deprecation from Mesos to Kubernetes. We manage deprecation from in the process of doing so from Istio to Cilium mesh. The users don't know that's happening in the background, but we're just doing it for them.