The hard things about dev tools with Felix Magedanz from Hanko
Hanko had paying customers, investor buy-in, and a growing proprietary auth business. Felix Magedanz's team dropped all of it to rebuild as open source — a decision that meant calling every customer, cutting the team in half, and betting on a passkey future nobody was asking for yet.
Felix Magedanz is the founder of Hanko, open-source authentication and passkey infrastructure for developers, which started life in 2018 as a proprietary auth product before pivoting entirely to open source in 2022.
We get into what it actually took to walk away from paying customers and investor support mid-flight, why the team had to shrink before the pivot could work, and how hitting 1,000 GitHub stars in days gave the company a kind of validation it had never felt from enterprise sales.
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 Hanko actually start, and what made you decide to pivot?
We started in 2018 building a proprietary SaaS tool to solve authentication better than Auth0, which was and probably still is the biggest player in the market. Our angle from the start was passkeys — we were convinced passwords would eventually be replaced entirely, not just supplemented, and we wanted to build for that future. But we were fairly inexperienced with open source and with selling to a developer audience — I'd previously led a software agency building for enterprise customers. We built Hanko 1.0 as a proprietary stack, made some bad architecture decisions that didn't scale well, but it still went reasonably well — the passwordless angle brought in real leads and customers. Eventually, in team meetings, we kept coming back to the question: we're building this for developers, so why aren't we doing it open source? That question sat there for weeks before we decided, in 2022, that we had to.
If the proprietary business was working, what actually pushed you to make such a drastic change?
We knew we could keep scaling the proprietary solution at a decent pace, and our investors were fully behind that path — it would have worked. But we were convinced the open-source path would work so much better, not just for go-to-market, but for us as a team. You have to be sure about what you actually want to work on, or you won't make it through. It came down to a choice between doing something we knew would work reasonably well, or something we believed would work very well.
What did actually executing that pivot look like — you had paying customers and revenue at stake.
It was, without question, the scariest and biggest decision we've ever made — though in hindsight, the best one. We had to drop the existing product entirely, which meant calling paying customers and telling them, essentially, this has nothing to do with you, but we're not developing this further. We offered to keep what they had running and support it, but there would be no new features. Every one of them was fine with it, which honestly wasn't the disaster we'd imagined going in. We'd also already started building out sales and marketing for the old product, so convincing investors that dropping everything we'd worked so hard on to start over as open source was a good idea was genuinely hard.
Beyond the customer calls, what was the hardest part operationally?
We had to become much more capital-efficient for the phase we were entering, since we'd have a product but nothing to actively sell, and we didn't want to split our small developer team's focus between maintaining the old product and building the new one. We ended up cutting the team roughly in half. Alongside the hard calls with customers and investors, having to make those decisions with the team was probably the worst part — not everyone could join us on the new journey. Everyone landed on their feet and found new jobs, and we're all still friends, but it wasn't easy, especially being the one delivering that news.
What advice would you give another founder facing a similar pivot?
Transparency, above everything. You can't bullshit your team or hide behind shady explanations — I tried to be fully transparent with everyone about what we were doing and why, and it was, in some form, a team decision to go this route. Even so, there were real motivation issues afterward, rebuilding the same category of thing over again — some genuinely hard months once the open-source project got underway. But because the remaining team understood exactly why the decisions were made, and even the people who left understood it too, we got through it.
How did you keep the remaining team motivated through months of rebuilding?
There's a point where a developer is genuinely happy to build the next iteration of something — the first version works, but it isn't beautiful, and now you get the chance to do it the better way, if not quite the perfect way. That helped a lot. There were still tough design meetings and workshops where we'd realize we'd had this exact conversation two years earlier and were having it again, partly because the original approach hadn't been well documented. But the reward came quickly — we set what felt like a modest goal of reaching 100 GitHub stars within six months. We hit that with our first 0.1 beta pretty fast, then launched on Product Hunt, and blew through 1,000 stars in two or three days.
What was different about that kind of traction compared to what you'd had as a proprietary company?
It was completely different, and genuinely rewarding in a way we'd never felt before — people coming into the community, asking questions, offering praise, because they simply liked what we'd built. With paying customers you get appreciation too, but it's a different relationship — they're paying you, often a lot, so their expectations are higher and they can be demanding. The open-source community dynamic was something new for us; there are bad actors in open source too, but we haven't really run into that yet.
How has your customer base changed since the pivot?
Before, about 10% of our business was inbound and 90% was outbound network sales — a classic top-down motion where we had to push into the market before developers got involved. That's completely flipped. We reevaluate this every few weeks, but for now we're fully focused on the individual developer. Our commercial product on top of the open-source core is priced at $9 a month, aimed squarely at an indie developer starting a new project — the complete opposite of before, and it means you need to reach a lot more people to succeed. We'll likely return to top-down sales eventually, but right now the path is making individual developers love us by focusing entirely on their needs, rather than getting pulled into things like a bank's specific 2FA requirements.
Was building for the individual developer always the underlying goal, even back in the proprietary days?
Ironically, yes — it was the plan from day one. When I first had the vision of building an auth solution around passkeys, it was clear we wanted to build it for developers. We just had no idea how to actually do that, and we learned it along the way.
How are you thinking about growth now that you're past the initial GitHub-stars spike?
That first rush gave us a great foundation, and now we're building on top of it. The first version let you integrate a login in 10 to 30 minutes depending on the framework, using web components — genuinely complex stuff underneath. We now have paying customers on Hanko Cloud, thousands of developers, thousands of free instances under a free tier up to 1,000 monthly active users. The next phase is living up to the expectations that come with entering a category people assume is 'solved' — supporting sign-in with Apple and Google seamlessly regardless of how someone originally signed up, proper mobile SDK support, and features enterprise-adjacent customers expect. We're also restructuring the API itself so someone who doesn't want our web components can still get huge value building their own UI directly on the Hanko API, without it being overly opinionated.
You're starting to hire beyond engineering. What does that first hire look like?
Right now it's just engineers and myself, plus Mia doing all the design work. The next role we're hiring for is titled DevRel engineer, but it's really an engineer who also enjoys communicating and writing, sharing their thinking with the world — not necessarily the strongest pure engineer, but someone with a real engineering background, because it's very hard to convince developers you understand their problems if you're not one of them yourself. The goal is someone who can work on docs and SDKs and grow into the communication side, not someone starting from communications and picking up technical skills after.
How would you measure whether that hire is succeeding in their first six months to a year?
You can track things like blog posts published, but ultimately it comes down to something intangible: developer love. Whatever creates that is good, whether it's organizing a hackathon at an event or something else entirely. But I keep stressing the engineering background because I think the most important lever is making sure your SDKs and documentation are genuinely great, and the experience of finding and trying your product is in the best possible state — invest there first, then talk about it.
What's the one thing you'd tell another dev tool founder based on everything you've learned?
Think seriously about the commercial side of it. A dev tool founder doesn't have to be chasing profit specifically, but to sustain what you're building, it helps to think honestly about how to make it work financially, and then make the decisions that get you there — even when they're hard, even when they mean going outside your comfort zone to hire people you have no idea how to find yet. You're probably already in plenty of Discord or Slack communities where you can share your vision and conviction, and it may take a while, but you'll find like-minded people who want to join you. It's stressful, with real ups and downs, but that's what I'd want another founder to hear.