Why I started Interfere

We’ve raised a $5.1M seed round, led by Hummingbird, with participation from Worldbuild, Designer Fund, Y Combinator, Vercel, and others.

We’re building Interfere to help teams understand what’s going wrong in their software, who it affects, and how to fix it. It started with a frustration I kept running into as a design engineer, working on products I cared about.

The tool I wanted to exist

As a design engineer, I became someone people could trust with an urgent problem, which I enjoyed. But over time, investigating bugs and keeping things running took more of the attention I wanted to spend on new features or rethinking parts of the product. Even when I got back to that work, it was hard to focus while I was still wondering whether something else was broken.

We had good tools for collecting information, but making sense of it still took a lot of work. An error might be harmless or it might mean a customer couldn’t do something important, and someone had to investigate before we could even decide how much we should care.

I kept thinking about what it’s like to work with a great teammate. You can hand them a problem and get on with your own work, trusting that they’ll come back with an answer or ask for help when they need it. I wanted a tool I could trust that way, without keeping part of my head in the work I’d handed over.

I called the original thesis “I Loved Her to the Point of Invention.” I loved building software and wanted more time to spend on the things that made it good, but so much of that time went into figuring out what had happened after we shipped.

A problem the whole team can understand

If I were explaining a bug to a colleague, I’d tell them that people couldn’t log in. Getting to that explanation in a monitoring tool might mean starting with hundreds of exceptions and working out what they meant for the people using the product.

Engineers end up doing that translation for the rest of the team, too. I remember a product manager telling me how carefully she managed her questions to engineers. She needed to understand what was happening in the product, but before she could ask, she had to decide whether it was worth pulling someone away from their work.

I wanted her to be able to find out for herself.

That’s why we’re building Interfere around problems and the people affected by them. The same issue might have a PM looking at which customers are affected and how much revenue they represent, while a designer looks at where the experience broke down and an engineer investigates the technical cause. They should all be able to get what they need from the same evidence.

What happens after we ship

With AI, designers and PMs are shipping code themselves, and engineers can hand off work that used to take days. I’ve spent my career wanting to turn more of my ideas into things people could use, so seeing more people able to do that is exciting.

But it’s possible to finish more work and merge more code without learning much about whether it helped anyone. Customers still have to find what you’ve built useful enough to pay for, and dependable enough to keep using.

I’d like us to spend more of the time AI saves understanding how people are getting on with what we’ve built. Once you know that, you can make a better decision about whether to fix something, simplify a flow, or remove a feature that didn’t need to exist.

That also means broadening what we consider a problem. If an onboarding flow works exactly as specified but leaves people unable to figure it out, whoever owns onboarding has a problem to solve, whether or not an exception fires. Helping teams understand those experiences was part of the original thesis, and it’s still where I want us to go.

What’s next

In an early investor update, I wrote:

We get one shot at our reputation, and I refuse to put a poorly built SDK into our customers’ codebases.

We’re now building that product with a team I’m incredibly proud of, full of people who want to use it themselves and have plenty of opinions about how to make it better. Getting to work with people who care this much has been one of the best parts of starting Interfere.

This round lets us bring more of those people together and get Interfere into the hands of more teams. Thank you to our investors for believing in us, and to everyone helping us build a product they want to use.

We’re hiring in New York, and if you care deeply about the things you make, I’d love to meet you.

I started Interfere wanting more time to build software I was proud of, and now we get to help other people do the same. I couldn’t be more excited to keep building it.