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.
00:32:39 · Jack
[00:32:39] S1: Mhmm. And then who does it go directly to the engineers? Like, what does it look like? If it's like, I I come in, I'm like, oh, well, can we do this? Or I guess I put that in Slack, say.
00:32:51 · Will Stewart
[00:32:51] S0: Generally, it starts with good docs. Right? So we try and have good docs, we have good examples, we have like one click stack stack templates with like pre created, like complex things that people can start with. We have some recorded videos that we share with some customers. And then generally in the onboarding, we sort of design out their architecture. It's like, let's understand your architecture. This is what it looks like in Northlink. So it's almost like we're training our customers to be their own internal solutions architects. And that is very effective because we want our customers, you know, a couple of people within within each customer to essentially do the internal, you know, internal selling to their developers like, how do you do this? How do you do this? And then, yes, over time, that means that in Slack we we then get very advanced questions, which is how do I do this? And then it's a question of, you know, trying to figure out is this possible, is this not possible? Building features, if we need to build features, we will build features, we'll put it on the road map, we'll say this is the timeline. And then we'll work with them to get things live. But generally speaking, over the last five years, you can imagine this feature matrix. We talk about feature matrix a lot at North Flank. Every single sale is a feature matrix because we're in developer tool. All of our customers are very very picky on exactly what they want. You don't meet, you know, you've got a thousand things and you don't have that one thing. Some people will not adopt your platform, they won't buy.
00:34:16 · Jack, Will Stewart
[00:34:16] S1: If it's the one thing that [00:34:18] S0: Exactly. It could be it could be anything. Right? Some some customers are very picky, quite rightly. So we've always seen this as a feature matrix. It's our job to reduce the friction on that feature matrix. We can if we can meet them where they're at, they're much more likely to adopt and move as many workloads to us as possible. [00:34:39] S1: What do you mean by reduce the friction on the feature matrix?
00:34:39 · Jack, Will Stewart
[00:34:39] S1: What do you mean by reduce the friction on the feature matrix? [00:34:42] S0: So if you can't do something, the developer's decision is, okay, well, I've gotta build it then. I'm gonna go and get Terraform, I'm gonna go and get Argo CD, I'm gonna go and build that platform because Northland doesn't support this feature, so we can't adopt So so we have to diffuse that situation. Right? This is everything we do. We do 99.99% of what what you need. So you can start testing dev, import workloads, get get started in, you know, a very short space of time. And then obviously, in these enterprises as well, we need this one feature. We need this one feature. And we start iterating in real time to win the contract. And then you build trust. Ironically, actually having a little bit of bugs means that they have to they have to talk to you and they have to come and talk to you. You have to be on the phone. You have be on Zoom. You have to oh, show me your environment. How does that work? And then they start telling you. And then you start building that relationship and then, you know, a few weeks later, they're running a thousand workloads on you. So so it's it's interesting that, you know, we're talking about bugs earlier. Sometimes that can actually allow you to talk to customers much more efficiently. And they sort of self identify, these are my workloads. This isn't working perfectly. So most of our enterprise contracts, you know, probably have come through support in some way or form.