Building computer vision tooling with Niko from Rerun
Niko West kept building computer vision products and kept hitting the same missing tool — until he decided he wasn't doing another computer vision project until it existed. Rerun's free tier is deliberately harder to build than its paid one: a single developer's tolerance for friction is much lower than a team's.
Nikolaus West is the co-founder and CEO of Rerun, which combines an SDK for logging computer vision and robotics data with a visualization tool for understanding it — something he describes as visual printf-style debugging for computer vision.
We get into the internal tool at a 3D foot-scanning company that convinced him this had to exist everywhere, why targeting individual developers turned out to be harder than targeting teams, why Rerun is built end-to-end in Rust, and the DM strategy that got them their first users.
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.
What is Rerun, in concrete terms?
It's two things: an SDK for logging computer vision and robotics data, and a visualization app that takes what you've logged and automatically builds fast, useful, good-looking visualizations to help you understand what your system is actually doing. A useful way to think about it is visual printf-style debugging, but for computer vision data.
How did the idea for Rerun actually come about?
My two co-founders and I previously worked at a 3D scanning company that scanned feet in physical retail stores to recommend shoes — a surprisingly hard problem, with a lot that can go wrong, and physical retail is a genuinely difficult environment to ship working computer vision in. Our CTO, Emil, came from the gaming world and approached debugging differently — he started building really rich visualization environments, and it became dramatically easier to see what was wrong and what needed to be built next. What started as an internal debug tool for algorithm developers ended up used by data labelers, operations, support, even sales calls — it permeated the whole organization and was a genuinely key part of that company winning its market years ahead of competitors. After I left and kept building mobile computer vision products, including an AR company, I kept hitting the exact same gap and kept assuming someone must have built this obvious tool by now. Nobody had. I decided I wasn't doing another computer vision project until this tooling problem was solved, and that's how the three of us ended up building it together.
Was starting the company an obvious moment, or something you talked yourself into over time?
I kept coming back to knowing someone needed to solve this properly — it had to become a real project eventually. What held me back for a long time was knowing that doing it right is a genuinely huge undertaking, and constantly asking whether the market was big enough yet, or too early. We spent a lot of time, starting a bit over a year before this conversation, talking to potential users and companies to figure out if the timing was finally right. What we found is that all the surrounding pieces — training and deploying models — had gotten easy enough that people were now actually shipping real computation-based products at scale. It ended up being much more a timing question than a conviction question.
How did you land on making the core product open source?
We had strong inklings from experience that open source, and developer adoption specifically, mattered enormously here. The first reason is that for tools like this, the genuinely new knowledge about how a product behaves is always generated by the developer actually working on it — they're trying to solve a real problem for themselves, understand how some part of an algorithm performs in some situation, and because of that they build genuinely useful explanations and visualizations. Tools built after the fact by a separate tooling team are just much less useful by comparison, so it's important for the developer or researcher themselves to be the one building a lot of the visualization, not a downstream team.
What's the second reason open source and a developer-led motion made sense for this specific market?
Computer vision has huge potential across wildly different markets — construction, security, agriculture, autonomy, augmented reality. Talking to developers early on, we noticed people move surprisingly fluidly between these industries — someone working in medical AI one year might be in AR or self-driving the next. It's genuinely the same developer, just landing in different verticals. That creates a market shape where there's one horizontal layer, the developer, sitting underneath many very different vertical applications. Trying to sell top-down into each vertical separately, with tailored landing pages and industry-specific sales pitches, would be nearly impossible to do broadly — you'd only ever be able to target a handful of the biggest accounts. Going bottom-up through developers directly lets you reach effectively all of them at once.
Does that change what actually convinces a developer to adopt something like this?
Exactly — these developers aren't excited by a white paper claiming five reasons you'll get 50% more efficient. They already know roughly what capability they want, or they see a video and immediately think, yes, I need that. You end up being able to sell on raw capability rather than a narrow, tailored pitch, which is a much broader net and has real implications for how you go to market with something like this.
How is the open-core split between free and paid actually structured?
The base version of Rerun is completely free and open source, under MIT and Apache 2, and it needs to be an incredible product on its own — targeted specifically at a single developer working locally on their own machine, with one robot or device. That's the use case we're optimizing hardest for. The commercial product builds on top of that, targeting teams working together on products already in production.
Why did you actually start by building for teams, if the free tier targets individual developers?
Counterintuitively, building for a single developer is harder — the friction tolerance is razor thin. The moment a solo developer hits something that doesn't work, they immediately jump to a less powerful tool they can at least hack around. A team is more forgiving; you can ship a narrower subset of features that solves their single biggest pain point and still succeed. So we actually started by working closely with a few teams, got a team-oriented version working well for them, and have been progressively pulling that experience apart to make it work better and better for the single-developer prototyping use case, which is still very much an ongoing process.
What specifically ends up in the paid, team-focused tier versus staying free forever?
Everything we build stays free and open source at its core. What we charge for is direct collaboration and syncing data across a team, because performance at that point becomes a genuinely hard problem — these datasets get very large, since we're not just visualizing your inputs and outputs, we're capturing the full internal state of your algorithms over time. If you're optimizing camera position relative to an image, you might want a rich view of that data for every single optimization step, which can be a hundred times more data than the raw input and output alone. Sharing and handling that kind of data volume well requires real infrastructure, and that's what the commercial product is built around. You can absolutely use the free product as a team today — you just don't get those collaboration features until the commercial layer is available.
Is there a simple mental rule for what's commercial versus free?
Pretty much — if something requires us to run a service on your behalf, that's commercial. It's simple for us to reason about, and it's easy for users to understand too — of course you'd pay for something we're actively hosting and managing for you. Developers can get frustrated paying for something that costs the vendor nothing to provide, but they're far more understanding when the cost clearly maps to an actual running service. As developers ourselves, we've felt that same frustration, so we deliberately designed pricing to avoid putting our own users in that position.
Since launching, you've gotten a lot of attention and GitHub stars. What actually drove that?
First and foremost, I think we're building something genuinely useful that a lot of people in this space have been quietly wanting for a long time — some had built their own internal version that then rotted once the original author left or the project fell out of maintenance. Beyond that, more tactically: our product is inherently visual, so even while everything was still closed, we spent months just practicing how to visually explain Rerun through short videos, seeing what actually resonated. None of us were good visual storytellers going in. We did that for four or five months before our public release in mid-February, and for the launch itself I worked closely with a real video editor to build a tight, under-one-minute video that clearly showed how everything works — that video did a lot of the work in getting our launch real distance.
You've mentioned direct outreach on LinkedIn as an early growth tactic. How did that work?
Early on, we had real success just DMing computer vision developers directly on LinkedIn — trying to keep it genuine rather than salesy, something like 'we're working on this, would love your feedback' or 'I think what you're doing is cool.' It's not scalable, but it was low-effort and got us into real early conversations with a lot of potential users who were also just happy to be noticed. LinkedIn specifically mattered because the broader tech community skews heavily toward Twitter, but a lot of people in more hard-science-adjacent fields like robotics and computer vision are actually more active on LinkedIn, sharing papers and interesting methods — a bit of an overlooked arbitrage, since it's viewed as less inherently cool by the wider tech crowd.
Why build Rerun entirely in Rust?
Rerun is built end-to-end in Rust — we use Apache Arrow, but our database is entirely custom, our renderer sits on top of wgpu, and our GUI framework is egui. It matters for a lot of technical reasons, but it's also been a genuinely effective growth driver, because Rust developers love talking about Rust with other Rust developers. Being visibly a Rust shop has gotten us in front of a lot of people we wouldn't otherwise have reached, purely through that community's enthusiasm for the language itself.
Has building in Rust also helped with hiring?
Constantly. Every time we've hired, I've been amazed by how much incredible talent is ready to switch jobs purely for the chance to work in Rust day to day. It's honestly a bit sad we can't hire all of them — we're small and have to match people to specific roles rather than hiring everyone good the old Google way — but any team out there struggling to hire while not offering Rust is genuinely missing out on a real advantage. If it's at all practical for what you're building, I'd say build in Rust.
What's the one thing you'd want other dev tool founders to take away from your experience?
What's worked consistently for us is that we're solving our own problem — I've personally lived with this exact pain for so long that the right thing to build is genuinely internalized, and several others on the team are in the same position. That matters especially with open source, where getting rich feedback can be harder, since people don't need to ask you anything, they can just use the product silently. But we always have that internal compass telling us exactly what to build because we're the ones who need it. Worst case, if it doesn't work out, we'll have built an incredible internal tool to build something else with. It's a hard tip to overuse.