At Niftic, we’ve been running experiments for about 10 years now. We’ve used all the major A/B testing tools, implemented feature flags in codebases, and tried pretty much every approach to experimentation you can think of. So when we decided to build our own experimentation platform – Oboe – it wasn’t a decision we made lightly.
Building your own tool is a massive undertaking. There are already established players in the market, and honestly, reinventing the wheel isn’t something we typically recommend to our clients. But after years of daily frustration with existing tools, we reached a breaking point where the pain of building something new was overshadowed by the pain of continuing with the same old.
The problems we couldn’t ignore anymore
The UI/UX is stuck in the past. Most experimentation tools feel like they were designed a decade ago and haven’t evolved much since. They’re manageable if you’re setting up an experiment once a week, but when you’re working within these platforms all day, every day, the clunky interfaces become a real productivity killer. Simple tasks take way longer than they should, and the cognitive load of navigating these systems adds up over time.
Developer experience is an afterthought. Having to build experiments through a web app – or worse, a desktop app that’s really just that same web app but extremely bloated – isn’t exactly inspiring for developers. The disconnect between where developers want to work (their IDE, their local environment) and where they’re forced to work (a slow web interface) creates friction at every step of the process.
Performance issues are everywhere. Experiments flicker on page load, QA becomes a nightmare when you can’t reliably reproduce what users will see, and every time you save changes, you’re in for a nice long wait. These aren’t just minor annoyances. They impact the quality of experiments and the user experience for your actual customers.
Pricing and contracts are frustrating. Most tools are expensive, require annual contracts, and hide their most useful features behind increasingly expensive tiers. When you’re running experiments at scale, these costs add up quickly, and the lack of flexibility in pricing models doesn’t match how most teams actually work.
What we built to solve them
Oboe was designed specifically to address the problems we face as a growth agency and the challenges our clients encounter daily. Here’s what we focused on:
A modern interface. We built Oboe to feel like software from this decade. The interface is intuitive, responsive, and designed for people who spend hours each day running experiments. You shouldn’t have to question what year it is when you open your experimentation tool.
Developer-friendly workflows. We’re building tools that work the way developers actually want to work – with code snippets, better interfaces, and local development support coming soon. Experiments should be as easy to build and iterate on as any other part of your product.
Speed that actually matters. We obsessed over performance – smaller snippet sizes, faster loading times, and no flickering. When your experiments load instantly and behave predictably, both QA and user experience improve dramatically.
Analytics that make sense. We included easy-to-understand analytics for quick decision-making, along with tools that let data scientists dive deep when they need to. The goal was to serve both the PM who needs a quick read on experiment performance and the analyst who wants to slice and dice the data.
Transparent, flexible pricing. Month-to-month pricing with no annual contracts required. We’ve been on the other side of those sales calls, and we know how frustrating it is when you just want to try something without committing to a year-long relationship.
Why it was worth the effort
Building Oboe wasn’t just about solving our own problems, though that was certainly part of it. We realized that the experimentation space had stagnated while the rest of the development world had moved forward. Tools that were innovative five years ago started feeling dated, and newer entrants were often just copying the same patterns instead of rethinking the fundamental experience.
As a growth agency, we’re only as good as our ability to run experiments quickly and reliably. When the tools slow us down, they slow down our clients’ growth. When the tools are expensive and inflexible, they eat into budgets that could be spent on actual experimentation. And when the developer experience is poor, it becomes harder to attract and retain the kind of engineering talent that makes great experiments possible.
The decision to build Oboe came down to recognizing that the problems with existing tools weren’t just minor inconveniences – they were actively hurting our ability to do our best work. Now that we’ve been using it for our own projects and with our clients, the difference is clear. Experiments that used to take days to implement and QA now take hours. Analytics that used to require exporting data and building custom dashboards are now available at a glance.
If you’re frustrated with your current experimentation setup, I’d encourage you to check out what we’ve built at oboeapp.com. We designed it to solve the problems we couldn’t ignore anymore, and I suspect you might be dealing with some of the same challenges.
