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? Hey, everyone.

You're listening to Scaling Dev Tools. I'm joined today by my friend Will who is the cofounder and CEO of North Flank. We're gonna get into what North Flank does in just a second. We talk about building a platform that runs complex developer workflows, how Will met his cofounder, which is a very interesting story. We talk about the balance between building something very reliable while shipping fast, And we also talk about stuff like how to update your users about what you've just built and responding to feedback.

Enjoy the episode.

So Northlink is a well, first of all, we're a UK based startup. So great to be here in person with you.

That's true. We're in a farm right now.

We are in a farmhouse. It it it's it's great because obviously you you started the UK DevTools meetup. So it's it's great to be here and and chatting with you today. And we've had this in person friendship for such a long time and finally get to be here. Northflank is a self-service developer platform.

That's the the core principle. And our primary objective is to help teams deploy the most critical workloads to production. We speak Kubernetes, so Northflank can run on any Kubernetes cluster. And that means that we can run anything from microservices to databases to message queues all the way to inference training. Pretty much we're a polyglot platform, which means we try and run everything, and we're in the post commit phase of the development life cycle.

So as soon as an engineer is pushed to version control, Northlink takes over from build, deploy, release, auto scaling, disaster recovery. And this primary happens in in your VPC. So if you want to use GCP, AWS, Azure, Oracle, CoreWeave, Northland can run on top of your Kubernetes clusters. But of course, we're not just building for enterprises and and and your VPC. We also operate as a PaaS.

Ultimately, that's our DNA. The developer experience is essentially a platform as a service. And in in doing so, someone can sign up in a couple of seconds, deploy services, and then later they could graduate to their own VPC or on prem. And that's that's where we are today. Obviously, it's taken we we founded Northlink in 2019, and it's it's taken us to this point.

Yeah. Actually, one of things

I wanted to ask you about is quite I always found it very unusual. It's like how you met your cofounder with that story and then maybe you could start with that and then transition on the actual story of North Flank. Yeah. Absolutely. So my cofounder and I so I'm the cofounder and CEO and Fred is my CTO.

We've known each other for a very very long time, maybe, I don't know, thirteen, fourteen, fifteen years, however long it is now. Can't remember exactly. But we mess in our multiplayer game. So I I had been trying to build a number of gaming communities as you do as a kid. You, you know, make a clan, you try and make a small gaming community.

Which game?

Mount and Blade Warband. Warband? Yeah. It's quite a niche game on PC on Steam.

But Yeah. What is it?

It was a medieval RPG game where you could build mods. There were a number of mods we used to, you know, support host game servers, things like that.

Yeah. Is it a little

bit like RuneScape or It's it's much more like it's it's it's more three d Okay. Than RuneScape. But I did play RuneScape as well. So we met online and then we started to build things together. So we started to build applications together.

And Fred's not in The UK? No. He's he's German living in Switzerland. And we haven't spent that much time in person together. Like, probably maximum a hundred and twenty days across those thirteen, fifteen years, whatever.

Yeah. We didn't meet until 2019. So it was already at that point.

So you met when you started it.

Right? So we met when we founded North Flank. Yeah.

But you'd already decided to

We'd already been building and working together for many many years. It's because we like we were kids, we couldn't afford to, you know, get on a flight and meet each other. So originally, you know, were on TeamSpeak. We were working on TeamSpeak. We were working on Skype.

Like, literally, there are old Skype conversations of us collaborating, trying to figure out how to build build shit, and and then we obviously graduated to to WhatsApp and Discord and then and then eventually Slack. So so yeah, I think it was in 2019 we decided, okay, if we're gonna do this properly, we need to go and learn how to code. We're gonna have to do this properly rather than just be script kiddies. So we both went off to university. Fred went and did his masters in computer science.

When you'd already when you say like, if we're gonna build this, like, we need to learn how to code, like, as in you'd already had like this, like, specific North Flank idea?

So that in like twenty thirteen, fourteen, fifteen, we were manually deploying game servers on bare metal on like OVH and Hetzner back in the day. Obviously, now Hetzner's now the hottest thing and everyone wants to deploy Well, you were deploying Yeah. We were then, we were like using our pocket money to spawn bare metal machines using, you know, SSH in and then try and run some game servers. And we were doing that in No thirteen, fourteen, whatever it was. And this is when public cloud just wasn't very available or couldn't even run game servers because the CPUs weren't fast enough or or whatever.

And also the network was really expensive. So we we we were provisioning these these bare metal servers, we're like, this is crazy, this this needs to change. And of course, every new game came out, and the multiplayer was always offline because game developers didn't know how to build an infrastructure platform. So we thought, okay, well, why don't we try and build this? Why don't we try and build an automation system for these game servers?

And then as time went on, we're like, okay, well, we need to deploy a back end. So we needed to go and deploy a database and a microservice. We looked around and the only thing at the time, you know, was Heroku. I had been acquired by Salesforce and it hadn't evolved. Like, I think at the time, you can even deploy a Docker image.

So we we thought we needed something more accessible. And of course, at that time, we'd learn containers, we'd learn Docker. And then Ben, sorry.

Just to get a reminder, how old are you at this point?

Oh, I think it's like a levels in The UK. It's a levels. Think

it's 16, like 17. Scaling DevTools is sponsored by WorkOS. If things start going well, some of your customers are gonna start asking for enterprise features. Things like SSO, SCIM provisioning, role based access control. You could spend ages tearing your hair out building these things yourself, or you could use WorkOS.

Will, what do you guys do?

My name is Will Stewart, co founder and CEO of Northlink. We're a self-service developer platform, and we help teams deploy their most critical workloads into their VPC. And you guys use WorkOS? We use WorkOS for our SAML and OIDC integrations. It's a pretty exceptional product.

It makes everything regarding authentication pretty seamless, and it's been instrumental for us to onboard our enterprise customers much faster. Building integrations with lots of different SAML providers is really challenging. We can do that for cloud providers, that's our job. But we don't wanna do that for the other type of IDP. This is quite interesting because internal developer portal platform and then there's the identity provider.

So IDP has three different meanings and we're internal developer platform and WorkOS is IDP for authentication. But yeah, it's a great product.

Thanks WorkOS. Back to the episode.

So we started building a game server hosting platform on top of Mesos. It was open sourced during our our I think we roughly went to school at the same time. Mesos is Mesos was a open source container orchestrator for for Twitter and and a few other folks. And D2IQ, Mesosphere at the time, they open sourced something called DCOS, data center operating system. I was like, oh my god, this is so cool.

Remind us. 1918. Yeah. I I took that and then I was trying to make it, you know, brute force it into a game server hosting platform. And then from there, we learned, okay, well, I need to deploy my database, I to deploy my microservice, I need CICD, I need logs, I need metrics.

And then suddenly all of the component parts we were like brute forcing and building ourselves to run on top of Mesos. This is like early twenty nineteen and at this point, Fred, who's studying to get his masters at computer science at ETH, I'm in my second For

anyone One of university. University.

Yeah. We're very lucky to have a number of team members from ETH. And and then I had I finished my second year of university at UE in Bristol, studying IT management for business, so a bit of business, bit of coding. And then I was on my third year, which was an industrial placement at a digital agency called Clock. I chose Clock because they did rugby websites, and they also did riotgames.com.

So at the time, that was great for me. That was gaming and sports, and I got to code, which was which was wonderful opportunity. Learned a lot there. And in in in that process, we had to decide, like, do we wanna do this full time or do we need to get real jobs? So we had to make a decision then of, how are gonna do this?

So we created a list of every accelerator program in Europe who would let us join remotely, because of course we were in two different places and couldn't really afford to move, and who would give us cloud credits. So, you know, now everyone tries to hunt for those cloud credits. Well, back in 2019, we were stuck ranking all the European accelerator programs who could give us access and also cloud credits. And we joined we applied to join the family

and That's in France.

It's it was in Paris. Yeah. And pitching Northlink for the first time. And this time we didn't tell them, we'd never met. It was like, you know, no concept of that was possible.

So we're trying to hide this thing, and then we we go through a couple of interviews. Some of our earliest angel investors were in that interview process, Pietro from Firedrop and Balthazar. They they were part of that interview process and they thought, okay, we'll give them a chance, let's let them through. And then we get invited to this, like, onboarding event, which is in person. We go, but the the kicker for me was that I had to use my overdraft to buy the train ticket Eurostar to get to Paris.

So it was a big investment. It's like, do I spend the £300 on the train ride or do I So I bought the train ticket, went into my overdraft, went to Paris, met Fred for the first time. There's a photo of us on on on some blog post on our meeting for the first time after ten years. And we're we're we're both quite tall, so Fred was quite disappointed to figure out that I was taller.

How tall how tall are you? How tall is Fred?

I'm like six three, six four, and Fred's pretty much the same. Okay. But slightly slightly smaller. And then we do this event, and then throughout the event, you know, we're trying to keep it quiet, keep them that we've never met. We're thinking this is insane, like we should keep that quiet.

And then someone someone finds out and then that really helps us build a relationship with a lot of the people in the accelerator. And

Because you're because it's like kind of a crazy story.

Yeah. I think it's less crazy now, but I think it was very uncommon at the time. Like at that point, remote was not a thing. Raising remotely, working completely remotely from your cofounder, never meeting your cofounder was pretty much unheard of. And then we we raised an angel round through the accelerator.

We kept building and then that started to snowball from there. Anyway, sorry. And just so when in 2019 so when you

were doing this, when you're going for the accelerator, you were like twenty twenty one.

Something like that. Yeah. And I I had to put my I had to put my placement on hold. I had to leave my placement to do this full time. So I had to basically drop out of university, leave the placement to to do this, which was a big call at the time.

And, you know, everyone in in my support network at the time was very very supportive. So I'm very fortunate that was that was the thing. And then, well, we just jumped straight head on. Like, this is an opportunity. Let's take it.

And then from there, we started to raise the angel around I just mentioned, hire people, trying to go from students to founders, build continue building a product, try and find our first customers, like, shit. This is for real. We actually have to do this. And we actually have a clock because if we don't do this, the money runs out. So then you're on this treadmill that just keeps getting faster and faster and faster, and I think we we had, you know, a very quick baptism of fire going to IC for the first time and essentially not knowing anything about VC or even meeting VCs.

And I think in that three month process, we just learned so much so quickly and then grew up very very quickly. But then that was that was still back in early twenty twenty. So when we when we had closed that pre seed round with Kindred Ventures in San Francisco, which we raised that round completely remotely, all on Zoom. And at the time, that was very unusual. This was, like, two weeks before COVID.

So then we had to start hiring all of our team and building out this startup in in those first couple of months of of COVID, which was which was, you know, pretty pretty interesting for, like, a 22 year old founder. You just raised this money from people you've never met. You know, like, how are we gonna do this? So that that was fun times.

That's crazy. Wait. That is quite interesting how you even would like manage to make connections and raise money from San Francisco investors like remotely and that was quite unusual as well, isn't it, for European?

At at the time, I think less so now, but we had a lot of folks gave us a lot of time. Larry, one of our angel investors introduced us to Steve Steve Yang, Kindred Ventures. And Steve was happy to chat with us at, like, on a Sunday. He was on holiday in Hawaii or something. Was chatting us at on Sunday.

And he he's got other things to do, right? But he was chatting with us asking, well, okay, well, tell me how what's your go to market strategy? Well, tell me more about that product, you know, why why is your better why is your decision there better than someone else? Like, why is this gonna work? What does it look like if this is successful?

And that was always the question that we're like, wait, he's he's he's asking us, well, what if this is successful? And that was a mindset change. So we're like, okay, well, is possible. How do we do this? And then that was forever, you know, that was our start, that was our way in that was given to us then.

Mhmm. And then so when you did raise them for like seed around like them, what was the first like you said hiring the like?

So we had to build, we just kept building build build. As you know, North Frank has, you know, very horizontal developer platform, tons and tons of features, it's about complex workloads. We probably have too many features, but the for us at the time, we thought if we were going to build a highly capable developer platform, and at the time, right, so Heroku, highly successful billion dollars in revenue, and on the other side you had Cloud Foundry with Pivotal and VMware. Multiple billion dollars in revenue, also very successful. But Kubernetes had sort of stolen that golden goose.

So at the time we were thinking, well, Norfolk needs to be sort of in the middle, very capable, powerful platform that had some of the deploy in your own VPC characteristics of Cloud Foundry, but also had that self-service developer experience of Heroku, who were trying to build this vision in the middle. So we'd like to say, well, Northlink is if Cloud Foundry and Heroku had a baby, that would be North Flank. And of course at this time, Mesos had been completely dominated by Kubernetes. So we were migrating our platform from Mesos to Kubernetes, we're trying to build for the future, build for okay. Kubernetes is gonna become the default way every enterprise is gonna run their software.

Fortunately, that that came out to be the case very very quickly. And started hiring our first engineers, build build build, and then we didn't launch for over two years. Really? No. So you're just building?

We were just building

Are you talking to

Customers and we were having people play around with it, getting free users in in internal alphas and betas. But we have this view that if it's if it's not robust, if it doesn't have certain minimum level of feature set, you can't reliably run your most critical production workloads, whether it be databases, microservices, or Conjobs. So we we spent such a long time building that core horizontal platform, which has now put us in really good stead today, which which, you know, in hindsight, maybe we could have launched sooner. We'll have more users, more hype. But actually, this has helped us build a really robust product for our for our most, you know, critical customers, and and we continue to have that view today is if we keep investing in product platform, teams will just be able to run more and more workloads.

That's our job is hunt those workloads, find the most critical workloads, get them running on Northlink no matter where they're running, you know, on public cloud, AWS, GCP, Azure, or or on prem. And then also we have the the self-service users running on our on our PaaS.

Do you have like just on the waiting to launch? Because I think this is something that you see a lot of different opinions on it. If you if someone was asking you for advice like another DevTools founder, how would you think about like whether when it's right to do what you did and when it's right, it's just

Yeah. So I think that developers are very picky now. Right? They expect a much higher developer experience, which is quite right to expect that. But for example, we communicated internally that every UI element in the in the platform has to feel robust, has to feel like it's being designed by a much larger engineering team.

It's gotta be very capable, it's gotta feel real time. And that's to build trust in developer tools specifically. You have to build trust over a very long period of time. You can lose trust overnight. So everything we do about customers is empathy for the developer, empathy that we're a critical path software.

If we don't do our job properly, they could lose money. Their websites could lose money, they they could be out of business. So whenever we think about what how we build software, it's critical path, we have to do our job properly, and if we don't, people will suffer. So when we think about it like that, and when I talk to other founders is, you know, don't rush things, think about security, think about, you know, production readiness, which is very much against what a lot of teams do. Right?

They just YOLO things to prod. Don't have dev environments, don't have staging environments, they just YOLO to prod. Don't necessarily think about security. You know, they I saw a few days ago that someone tweeted out an internal dashboard of someone's data. Right?

That's just a no no. Think very carefully about what you're building. I guess for some dev tools, it's much easier to just put it out there, see if you people are interested. That's that's that's one of the benefits of doing so. You build an audience and become build an audience.

And when you're stopping people signing up or or not using your product, that's actually sort of shooting yourselves in the foot. So that's what we have, you know, we we you've gotta find that balancing act. So I would also say, actually, don't do exactly what Norfolk did. Release earlier. Write that blog post.

Make that YouTube video. Because if you don't, who's gonna make it? So I think if we were to do this again, we just would've written a lot more content much much sooner. We would've tried to get the word out and build an audience. So for example, I I don't really tweet very much, I'm not really on Twitter.

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.

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.

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

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?

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.

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.

They We we were a customer. They're great.

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.

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. 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.

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.

No. No. Every we've we've we've never done that. Like as a platform, everything's just happened behind the scenes.

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?

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.

Mhmm. Because you're pushing the edges, I guess.

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.

And who As in they're open to like moving faster.

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.

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.

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.

If it's the one thing that

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.

What do you mean by reduce the friction on the feature matrix?

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.

Okay. Strategic bug. Strategic bug. Exactly. Maybe you should like turn on like a bug.

Like something that you could just fix it immediately and see this thing.

We we had a actually talking about this, we we had like a we have a theming system and we built that early. That's controversial to build build a theming system, but we we created some like rogue themes. We were thinking of like just turning them on or like someone would sign up, but we I don't know, we we think he was snooping around the platform or something, let's turn on the pink theme or something. And they say, why is North Link doing this?

Yeah. Wait. So like a capacity meeting?

Oh, something like that. Yeah. We didn't do it in the end.

Wild theme. Yeah. Okay. That's that's brilliant. And actually, so when like you share the road map with someone like I know this maybe it's getting really into the weeds, but it's something that I've started to have to do is like, you know, like what how do

you do that well? So we This is counter to what most people do. Okay. Alright. We do not publish a public road map.

Interesting. Because it's never what anyone wants to see. Right?

They just wanna know their future.

I want my road map. Where's my road map? And like, your future is important. We're working on it. We're prioritizing this.

These are the things we're working on that may be relevant to you. And then we're just very honest. Like like, we think we can do it in this quarter, it will be in next quarter. But also, if we we think it's like a highly important, like, this workload makes sense or this feature makes sense, we'll try and get it shipped in twelve hours, twenty four hours. So we may roll out the feature, feature flag, say, oh, hey, by the way, we managed to release that.

So recently, we were trying to win a win a a deal that was important to us, and we we made critical changes to improve how we manage custom domains and generation of domains and importing, you know, wildcard certificates, whatever it is. We made some changes. A couple of days later, we win the deal.

That's

cool. So so making these changes, as long as it makes sense and it's in your, you know, wheelhouse and product vision, you should just make the change as quickly as possible because that builds trust, that builds a really important customer relationship.

Okay. So you're basically saying like, don't don't worry about how well you communicate, when it's gonna come

just by Just work on it.

Just

Yeah. Yeah. Like you may you may might spend more time making your roadmap pretty than actually building the feature. Right? So historically, we had a very, you know, weekly change log or whatever.

It was very detailed. Now we just do once a month. Mhmm. But this change log, we would get every feature very detailed in there, and then people would send us an an email saying, oh, hey, Northlake. I signed up because of how detailed your change log was.

Really? I'm like, okay. Okay. That's interesting. And then if we forget or don't post a release note, users will send us messages saying Really?

Hey, is Northlake okay? You you you dying? Do you need money? And we're like, no no no. Just log in, you'll see all the new stuff and blah blah blah.

They're like, oh, cool. Great. Great. Yeah. I saw that new feature.

I I was curious why you hadn't posted about it. That so so so so very quickly, our users will will figure out, oh, this feature hasn't seen an update in a while or what's going on here? So so all those users you have are always thinking about, what was the last thing this this website changed? Like, this button hasn't moved for a while. This this this feature is is is pretty stagnant.

So, yeah, we do have a lot of customers who are very very hard on our heels. Like, you've not updated this feature in a while. What's going on?

I was I've heard this before and it's like blind spot for me because like I never really read someone's change logs unless it's like, oh, okay. I'm gonna make an update to like a package or something and I need to see if it's gonna break everything. I I've heard this before. Was like, someone else was saying, like, just ship a lot of stuff and talk about it and like that's your that is your marketing. Your change log is your marketing.

I think I I think at the time back in 2020 or 2021, whatever it was, Linear had like the the change log and everyone was, yeah, everyone's gonna have a change log. Ultimately, a change log is just released notes, which is is very common as well. So it's been it was important for us, and then that was one way to build trust. And again, it comes back to trust. Does he does he use a trust that you're building the right road map?

Are you building a road map for them? Or are you actually focused on someone else? That's that's the real time evaluation that they're making. Yeah.

Okay. Final question, Will. AI obviously has impacted what you guys do a lot. I guess, like everyone's running compute. There's like scramble for GPUs.

How how's it changed things?

So I think I think it's quite interesting because obviously it's had a big impact on the software development life cycle. So far, it hasn't really affected infrastructure and DevOps per se. Like, you wouldn't have your AI agent deploying the most critical workloads. Like, that that hasn't happened yet. And also, it's not very good at it so far.

Impact for developer platforms like Northland is that historically, there were the terms of, like, ML Ops ML Ops platforms. So it's like a DevOps platform but just for ML engineers. Well, now with Northlink, you can do the same thing. You can deploy your AI workloads, inference training, you know, PyTorch jobs, notebooks, whatever you need to run, you can run that on a developer platform like Northlink. So for us, it it's again extending that polyglot vision, which is the best AI teams, they need to deploy inference, training.

They also need to potentially deploy secure runtime. And what's the core pinnacle underpinning of a developer platform in the past? Secure runtime, running untrusted code at scale. Mhmm. So we've been doing this since 2019.

And that means that all of these, you know, agent companies who need to do code gen or spin up temporary sandboxes can do so perfectly on Northlank. And then GPUs. Where does the GPU go? It goes on to a VM or or a bare metal machine, and generally, how is that orchestrated Kubernetes? So for North Flank, I think we had a GPU workload support to Northlink, like, two years ago or over two years ago.

So slightly before the full AI boom. But, you know, we had startups signing up wanting to orchestrate their their GPUs, we're like, okay. Cool. Okay. Okay.

Now these are available in public cloud, so, you know, a few years ago, a small amount of v one hundreds or whatever. But then people say, we want a one hundreds, we want l fours, t fours, all all of these new chips started coming out, And then it was it was great to see. It's like these new types of workloads, great new types of workloads, let's make them run on North Flank. So helping a lot of startups get their, you know, training jobs running and their inference. And for us, it just means more compute, more workloads, more clouds.

Right? Now people are looking for near clouds. They wanna be on Callweave. They wanna be on Together AI. They want to be on Lambda Labs.

All of those folks so they either started out selling, you know, the the the the, you know, the research machines or the gaming machines, or they started out in crypto. They've all come in to build these massive, highly capable, highly performing developer clouds for AI. Started out bare metal, and now pretty much all of them are now trying to default to offering all of their compute through Kubernetes. So we've gone through the same cycle as the enterprise, which is the enterprise now runs all of their workloads on Kubernetes. And what's Northlink's primary objective?

Fix Kubernetes. Make Kubernetes work for your developers. So Northlink's actually a really great place for you to build and deploy your AI workloads. Even though that's not our core mission or original idea, it's actually an AI workload is just a Git repo, a Docker file, and running lots and lots of containers. So instead of a CPU, you've now got a CPU and a GPU.

That's that's how we've seen it. And now it's a

huge opportunity for us. And, yeah, it's getting exciting. Amazing. Amazing. And where can people go to learn more about you and about North Flank?

So you can go to northflank.com or co.run, and you can self serve sign up. We have a free developer tier to deploy two services, a database, and a job all for free. And please reach out if you have any questions.

Amazing. And we can also they can also meet Will at some London DevTools meetup, boo.

Absolutely. And and absolutely. One of the best meetups in in London.

Sorry. I didn't mean to plug. What? This is your this is your plug, Will. So Well, thank you, Will, and thanks everyone for listening.

Hope you enjoyed it.