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.
00:28:31 · Jack, Will Stewart
[00:28:31] S1: So they they won't get like spammed by they're not getting spammed by you of like, make this change before July 1 or No. [00:28:38] S0: No. No. Every we've we've we've never done that. Like as a platform, everything's just happened behind the scenes. [00:28:43] S1: That's really cool. So this is the thing that you said a lot of stuff about like that I think is sounds like it's very obviously important to you is like being reliable, it's like being stable, It's like quality. So when when in my head I'm thinking, okay. So like there's always trade offs and stuff. So how are you able to like also keep like shipping fast and building things fast? [00:29:08] S0: We do make bugs. We do make bugs. Okay. Right? So our users in Slack will tell us. So, you know, this software is not perfect. Right? So even, you know, we we use Google Cloud, we use a number of providers, you know, we we feel that those are great platforms, but we're also reporting bugs on a regular basis. [00:29:31] S1: Mhmm. Because you're pushing the edges, I guess.
00:29:32 · Will Stewart
[00:29:32] S0: Exactly. So we we we know that even in the most critical platforms, there are bugs. So it's acceptable to have bugs. The question is how quickly are gonna fix them? So if we're making changes every day, if we're rolling out big releases every week, something's gonna break. And then we have, you know, direct connection with thousands of customers, whether it's on Slack or email. We'll know very very quickly if we've broken something. And I think this also builds on this concept of how we think about control plane, separation of control plane and runtime. So because Nord Flank is built on top of Kubernetes, some of our customers are in AWS, GCP, Azure, you know, all around the place on prem as well. So we have a we've infinitely made our problem even more challenging because it now has to work consistently on every single cloud. Yeah. And that's that's the design around Kubernetes is if we can make it work in Kubernetes, we can make it work anywhere. So we've we've got all of these different mediums, we've got thousands of features, and we have to make them consistent in every single deployment target, which which makes things more challenging. But at the same time, we only have an engineering team of 18. So how does a team of 18 people build such a horizontal complex platform and make it work consistently across all of these platforms? How does it? Brute force. Right? It's a lot of work. It's a lot of asking the questions, you know, testing, manual testing, manual does this feature make sense? Does this work with this feature? And it's a lot of, you know, product calls, discussion, and releasing features early to a small set of customers who you know have the same worldview as you do.
00:31:16 · Jack, Will Stewart
[00:31:16] S1: And who As in they're open to like moving faster. [00:31:19] S0: Not necessarily moving fast because these guys are like, if you break my production workload, you're done. You're done. Right? Like it's it's over. So so these are the folks that believe in the worldview of the Northland platform and don't want to build their own platform. So this all boils down to the most sophisticated engineering teams we work with have already built these platforms, but they do not want to do it ever again. They could they could couldn't care less about having to log into Kubernetes and write another YAML file. They do not want to touch another chart. They do not want to build from scratch. They want to build on top of something that's already there. And in doing so, we can release very complex features very quickly. Our users just, you know, eat it up, like, what about doing this, what about doing this? And then in real time on Slack or or or support or a Zoom call, we can, you know, sort of modify slight features, enhanced features, something we may have forgotten, and then our engineers are just, you know, shipping it out, and then we're able to have that real time conversation. It's I guess in a weird way, it's like building a consumer application that you're, you know, getting so much feedback so quickly to develop a platform. The customers we work with, they can pick up new features in in seconds. You know, they're building and deploying their code all day. If something goes wrong, we're gonna know about it very quickly.