I never set out to build a developer tool, let alone a search engine platform. My background is in design and product, not writing low-level code. Yet here I am, a designer who co-founded a developer tool company. The journey didn't start at any specific time but rather became a passion over years of behing exhausted by the same tools with the same annoyances void of inspiration or delight. The choice always seemed to be between wrestling with an ok open-source tool that either does half the things you want or required deep specialized expertise, or hand our fate to a SaaS tool with eye-watering costs. Along the way, I felt the misalignment between who builds search tools and who uses them. The people who created the legacy search systems weren't the ones in the trenches trying to integrate search into a live product on a tight deadline. I was convinced there had to be a better way.
Push and Pull
Coming from a design background, I approached building our developer tool, Searchcraft, differently. Instead of assuming users would bend to the tool, we designed the tool around the users (the developers, product managers, and even content teams who rely on search). This design-thinking approach meant focusing on clarity, reducing complexity, and creating a delightful experience in a domain usually known for concepts that fail to get abstacted effectively.
I've always loved the tension between designers and developers. That awkward, beautiful push and pull that happens when you try to turn an idea into something real. When you care about the how and the why equally.
It's not always easy. Sometimes it's frustrating as hell. But the outcomes are almost always better. Eyes light up at unexpected moments. You ship something neither side could have done alone.
That kind of collaboration changes your perspective. You start to notice where tools create distance instead of clarity. Where processes protect control but stifle creativity. Where the people with the ideas are cut off from making them real.
And you start to wonder: why does it have to be like this?
When Builders Aren't the Users
Traditional search infrastructure has long suffered from a disconnect. On one side, you have search engines like Elasticsearch or Solr, born from brilliant engineering but complex, requiring standing up clusters, managing devops, and constant tuning and reconfiguring via command lines. On the other side, you have newer SaaS services like Algolia that make search easier to adopt but often become prohibitively expensive at scale. In short, search has historically been an infrastructure headache that eats up engineering time and becomes a hidden drain on budget that's rarely accounted for. I felt this pain firsthand as a product designer trying to deliver good discovery experiences; the tools at my disposal were either too CLI-heavy and complex, or simplified to the point of opacity. Neither was ideal for a fast-moving product teams focused on user experience, ROI, or traction.
This misalignment exists because, traditionally, search tools were built by back-end search experts for back-end search experts. The everyday developers (and designers) who implement search were second-tier considerations. This has created powerful systems that often aren't designed with today's front-end developers, product owners, or the next generation of no-code builders in mind. I remember craving simplicity and clarity and fun, and I suspected that even veteran engineers were weary of the unnecessary complexity.
Breaking the Legacy Lock-In
One of our strategic goals with Searchcraft was to break the legacy lock-in of traditional search solutions. Search tools are a great example of what I've come to think of as "legacy lock-in by fear." They're powerful. No doubt. But they're also heavy, brittle, and weirdly sacred. Nobody loves using them. But everybody uses them. Why? Because they're safe. Because choosing the same tool as everyone else means nobody gets blamed.
Meanwhile, the people actually building things are stuck. They spend hours tuning something only to wait days to see if it worked. They jump through hoops to make small changes. They live in infrastructure when they want to live in ideas. And maybe they're not even developers. Maybe they're designers, marketers, or PMs who know exactly how information discovery should behave but are too restricted by legacy platforms and outdated processes to shape it.
That's the part that broke my brain. Not that the tools were hard-but that we just accepted that and moved on, which is a pattern we've been holding for two decades.
My team aimed to change that by building a solution so straightforward and powerful that switching off the old stack is a no-brainer. In doing so, we had to bridge the gap between performance and ease-of-use that legacy players never quite closed. Our ideal existance puts us somewhere between the power, performance, and enterprise toolset of Elasticsearch with the user experience and managed options of Algolia, all while being available as both a fully flexible on-prem solution or a cloud-based service. It's a daunting feet, but the current landscape begs for something refreshing and we aim to get there one bite at a time.
From Backend Plumbing to Engagement Engine
Perhaps the most exciting thing about approaching search from a design and product perspective is reimagining what search could be for a business. Historically, search was treated as backend plumbing - a necessary piece of infrastructure, but not something that directly drives strategy. Because we are a product team, we're taking a different view: search can be a core user engagement and monetization layer if you build it right. When a user searches on your app or site, that's a moment of intent - a moment you can either fulfill brilliantly or squander. We wanted to help teams make the most of those moments.
That's why we talk about breaking the mindset of search as just a cost center. In fact, we've seen how a well-designed search can turn into a revenue stream for our customers. A better search experience means users find more content (driving engagement), increases domain authority (better SEO), improves conversion rates, and opens the doors to serve relevant sponsored content or ads alongside results or even builds potential for an in-house retail media network (driving revenue). Search and content discovery is a core foundational pillar to any platform (alongside auth, analytics, security, and more) yet often remains an afterthought when it could really be a growth engine for the business. It's time to change that by redefining developer tools as business drivers and customer-facing experiences.
Who gets to build dev tools?
Reflecting on this journey, I realize it exemplifies a broader shift in our industry. Developer tools no longer have to come only from deep-in-the-weeds system engineers. Increasingly, unorthodox perspectives are reshaping the infrastructure layer. In our case, a designer helped build a search platform. Elsewhere, you see front-end developers rethinking cloud platforms, or product managers creating developer services. These "outsider" influences are in fact becoming superpowers. By stepping outside the old assumptions, we can create dev tools that are both powerful under the hood and delightful to use on the surface.
As a designer-founder, I've learned that developers appreciate good design more than our industry often gives them credit for. The senior engineers and architects I speak with don't want fluff - they'll see through marketing hype in a second. But they do want tools that make their lives easier without compromising on capabilities. They want scalability, reliability, and ROI, packaged in a developer experience that isn't a pain. Delivering that requires collaboration between great engineering and great design. It requires asking basic questions like "why does it have to be so hard?" and having the audacity to answer, "Maybe it doesn't."
I believe the future of dev tools will be defined by this kind of cross-pollination. The next generation of infrastructure products will come from diverse voices who challenge the status quo. And that's good news for all of us. It means tools that are more accessible without losing power. It means faster integration, fewer headaches, more transparency. In the end, it means developers can spend more time building the unique features that matter to their users, and less time wrangling plumbing. That's the vision that keeps me excited: a world where even the lowliest infrastructure can be elevated by design and fresh thinking into something that feels high-level and human-centric. If Searchcraft is any indication, when a designer (or any non-traditional thinker) builds a developer tool, you just might get a product that surprises everyone - not by being flashy or hyped, but by working so effortlessly that it changes what you expect from the tools you use. And in my mind, that's the highest compliment a dev tool can earn.