All episodes

“I met my cofounder while gaming” - CEO of Northflank, Will Stewart

Will Stewart didn't meet his Northflank cofounder Fred in person until 2019 — a decade after they'd started building things together online, having met in a Mount & Blade Warband gaming clan as teenagers. He explains why Northflank has never deprecated a single feature since founding, and why the company refuses to publish a public roadmap.

Jack Bridger
Episode 16745:06

Will Stewart is the CEO and co-founder of Northflank, a self-service developer platform that runs complex workloads — microservices, databases, message queues, inference and training — on Kubernetes across any cloud or on-prem environment. The company's origin is a teenage gaming side project: Will and his cofounder Fred spent their pocket money manually deploying game servers on bare metal providers like OVH and Hetzner years before either of them had properly learned to code.

In this episode Will talks through meeting Fred online and not in person for ten years, raising a remote pre-seed round from Kindred Ventures in San Francisco two weeks before COVID hit, and why Northflank spent over two years building before launching publicly. He also gets into how an 18-person engineering team keeps a horizontal, feature-heavy platform consistent across every cloud, why the company has no public roadmap, and what a monthly changelog does for customer trust.

The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.

How did you and your cofounder Fred actually meet?

We met playing Mount and Blade Warband, a fairly niche medieval RPG on PC where you could build mods to host game servers. We started building things together from there, and kept working together for maybe thirteen, fourteen, fifteen years over TeamSpeak, then Skype, then WhatsApp and Discord, then eventually Slack. Fred's German, living in Switzerland — we probably spent a maximum of a hundred and twenty days together in person across that whole time, and we didn't actually meet face to face until 2019, at an accelerator event in Paris. There's a photo of us meeting for the first time after ten years. We're both quite tall, so Fred was disappointed to find out I was taller — I'm six three, six four, and he's pretty much the same, just slightly smaller.

What got you from hosting game servers to building a developer platform?

Around 2013 to 2015 we were manually deploying game servers on bare metal — OVH, Hetzner — using our pocket money to spin up machines and SSH in. Every new game that came out, the multiplayer was always offline because game developers didn't know how to build infrastructure. So we thought: why don't we build an automation system for that? Then as we needed to deploy a database and a microservice ourselves, we looked around and the only real option was Heroku, which had been acquired by Salesforce and hadn't evolved much — I don't think you could even deploy a Docker image on it at the time. So we decided we needed to build something more accessible ourselves.

You raised your pre-seed from Kindred Ventures in San Francisco, entirely remotely — what was that like for two European founders who'd never met their cofounder?

One of our angel investors, Larry, introduced us to Steve at Kindred Ventures. He was happy to chat with us on a Sunday — he was on holiday in Hawaii at the time — and kept asking us what our go-to-market strategy was, why our decisions were better than someone else's, what it would look like if this actually worked. That last question was a mindset shift for us: he was asking what happens if this is successful, and we hadn't really been thinking that way. We closed that round with Kindred completely remotely, all on Zoom, about two weeks before COVID hit — which at the time was very unusual, especially for European founders raising from San Francisco.

Why did it take you over two years to actually launch?

We had this view that if the platform wasn't robust enough to reliably run people's most critical production workloads — databases, microservices, cron jobs — then it wasn't worth putting out there. So we spent a long time building that core horizontal platform before we launched, which in hindsight has put us in a good position with our most critical customers today, even though we probably would have had more users and more hype if we'd launched sooner. If I were advising another dev tools founder now, I'd actually say don't do what we did — write the blog post, make the YouTube video, get the word out much earlier. We could have built an audience a lot sooner than we did.

How do you balance shipping fast with the reliability your customers need for critical workloads?

We do make bugs — our users tell us about them in Slack all the time. It's acceptable to have bugs; the question is how quickly you fix them. Because Northflank runs on top of Kubernetes across AWS, GCP, Azure and on-prem, we've made our own problem harder by needing everything to work consistently on every cloud. We're only an engineering team of eighteen people, so honestly it comes down to brute force — a lot of manual testing, a lot of asking whether a feature makes sense with another feature, and releasing things early to a small set of customers who share our worldview and have a direct line to us on Slack or a Zoom call.

Why don't you publish a public roadmap?

That's counter to what most people do, but a roadmap is never quite what anyone wants to see — everyone wants their specific feature, on their timeline. Instead we're just very honest: this is what we're prioritizing, we think we can do it this quarter, or it'll slip to next. But if something's genuinely important, we'll try to ship it in twelve to twenty-four hours instead of publishing a promise about it. We were recently trying to win a deal, made critical changes to how we handle custom domains and wildcard certificates, and won the deal a couple of days later. You can spend more time making your roadmap look pretty than actually building the feature.

How much does the changelog actually matter to customers?

More than I expected. We used to publish a very detailed weekly changelog, now it's once a month, but people have emailed us saying they signed up because of how detailed it was. And if we ever forget to post a release note, users message us asking if Northflank is okay — one literally asked if we needed money, because nothing had changed in a while. Customers are constantly evaluating whether you're building the right roadmap for them just by watching what changes and what doesn't.

With such a broad, horizontal platform, how do you decide which customer feedback to actually act on?

We think of it as a feature matrix — every sale comes down to whether we cover everything a customer needs, and it's our job to reduce the friction on that matrix. You can't just take one customer's feedback at face value, because if you build a feature for them it might break something for someone else. So we take the average across five to ten different opinions rather than reacting to any single ask. And every feature we build has to be available in the UI, API, CLI and GitOps — a product manager might live in the UI, a DevOps team might live in the CLI and APIs, but they all need the same feature set underneath.

How has AI changed things for Northflank?

It hasn't really affected infrastructure and DevOps itself yet — you wouldn't have an AI agent deploying your most critical workloads, and it's not good enough at that yet. But it's extended what we already do: an AI workload is really just a Git repo, a Docker file, and a lot of containers, except now it's a CPU and a GPU instead of just a CPU. We added GPU workload support a couple of years before the AI boom really hit, so when startups came to us wanting to orchestrate GPUs, we were already there. A lot of the newer GPU cloud providers — the ones that started out in gaming or crypto — have ended up converging on Kubernetes too, so we've gone through the same cycle the rest of the enterprise world has.

Links & references

This episode is brought to you by WorkOS.

Keep listening