From Firefighting to AI-Powered Database Reliability: How NeverBlink Hit $1M ARR in 18 Months - Code Story

There’s a particular kind of chaos that happens when your production database goes down at 2 AM. If you’ve ever been there, you know the feeling—the adrenaline spike, the scrambling to understand what went wrong, the frantic debugging while your service hemorrhages money by the minute.

For Itamar Syn-Hershko, that chaos became the origin story of NeverBlink AI.

Before NeverBlink, Itamar ran a boutique consulting agency called Big Data Boutique. They specialized in helping companies solve their hairiest data problems. The work was intense—they’d get called in when things were already on fire. A real estate platform like Craigslist suddenly loses search functionality. An enterprise’s analytics database grinds to a halt. The pressure is immediate, the stakes are high, and the clock is ticking.

After responding to enough of these emergencies, Itamar and his team noticed a pattern. They kept building the same debugging tools over and over again. They were doing detective work that felt repetitive, even if each case had unique details. So they did what smart consultants do: they built internal tools to make their jobs easier and faster.

One of those tools got traction. Customers started asking for it. Within 18 months of turning it into a product, NeverBlink hit $1 million in annual recurring revenue.

The MVP That Wasn’t Pretty (But It Worked)

Let’s talk about how NeverBlink actually started, because it’s a masterclass in pragmatic product development.

The first version wasn’t a polished SaaS application. It was scrappy—a collection of scripts, some metrics pipelines, and one giant Grafana dashboard. Think of it as organized chaos. But here’s the thing: it solved a real problem that existing tools didn’t address.

Most database monitoring tools focus on surface-level metrics—CPU usage, memory consumption, disk I/O. They tell you that something is wrong, but not always why. Itamar’s team realized they had access to something more valuable: a breadth of information that could be correlated to find root causes.

So they started building scripts that didn’t just look at node metrics. They analyzed query patterns. They correlated unusual traffic spikes at specific times with CPU pressure. They connected application behavior to database performance. If you had an unexpected surge of queries hitting your Elasticsearch cluster at 10 PM, NeverBlink could tell you not just that your CPU was high, but why—and what was actually causing the problem downstream in your application.

That 360-degree view of database health became the foundation of their product.

The Trade-Off Every Founder Faces

When we talk about MVP decisions, we’re really talking about trade-offs. Itamar is refreshingly honest about what NeverBlink sacrificed in those early days.

“We basically built something that our market was demanding,” he says. “Or not even market—the customers were demanding.”

The trade-off was quality versus scale. Early NeverBlink could monitor one database cluster at a time. It wasn’t designed to handle multiple customers with massive scale. But that was fine because each customer who needed help was in crisis mode. They needed a solution now, not a theoretically perfect one.

So Itamar’s team would help one customer, learn from that experience, improve the tool, and repeat. Version 2 of the MVP was a refinement. Version 3 was better. Eventually, they refactored everything into something more holistic and scalable.

Here’s what’s interesting: even today, with NeverBlink serving multiple enterprise customers, there are pieces of that original MVP still in the codebase. Parts that aren’t optimally built for scale. Parts that occasionally cause problems or waste money. But they haven’t ripped them out because the team is too busy building the next big feature.

“Maybe sometimes building software is just evolving an MVP to version 20, version 200,” Itamar reflects. “You never get something complete. You just replace those pieces as you go along, attending to the most painful pieces or the biggest bottleneck that you have at that time.”

That’s not a bug in his development process—it’s a feature. It’s how you stay lean while growing.

Building a Team of Problem-Solvers

One decision Itamar made that he’s now reconsidering: he didn’t hire a product manager until recently. For a long time, NeverBlink was built by engineers, for engineers, talking directly with engineer customers.

“We did product managerial roles and tasks that we weren’t product managers ourselves,” he admits. “So maybe we didn’t do it right.”

The result was mixed. Some features they built became beloved by customers. Others launched to crickets—nobody used them. But the direct customer feedback loop also meant they were building things that mattered to real people solving real problems.

When it came to hiring, Itamar looked for a specific type of person: technically excellent problem-solvers who could handle any curveball. People who weren’t just good at their specialty, but good at figuring things out. Many of his early team members came from the consulting business, which meant they already understood the domain deeply and had worked with real customers on real crises.

This created a virtuous cycle. The same people who consulted with enterprises on their database problems also built the product. Customer insights flowed directly into product development. The team wasn’t separated from the market—they were the market.

Scaling While Bootstrapped

Here’s a constraint that shaped everything: NeverBlink is bootstrapped. No VC funding. No war chest to hire ahead of demand.

This meant Itamar’s team couldn’t afford to over-hire. They had to onboard new customers and handle significant scale increases with the same team size. They had to figure out special cases—weird database versions, unusual cluster configurations—while maintaining service for existing customers.

“Scaling the team is always a challenge,” Itamar says. “We need to be able to accept projects or onboard customers with significant scale and be able to support them while they onboard.”

It’s a constraint that forces discipline. You can’t hire people on speculation. You can’t build features that don’t matter. You have to focus ruthlessly on what actually moves the needle.

The Shift to AI-Powered Reliability

What’s fascinating about NeverBlink today is where it’s heading. The platform started as a detective tool—helping teams understand what went wrong after it went wrong. Now, with AI capabilities baked in, it’s becoming more predictive and prescriptive.

The problem NeverBlink solves has only gotten more urgent as companies have scaled their data infrastructure. Database reliability isn’t a nice-to-have anymore—it’s mission-critical. And as databases have gotten more complex, the need for intelligent monitoring that can correlate multiple signals and identify root causes has become essential.

The Takeaway for Founders

Itamar’s journey offers some lessons worth stealing:

Build tools for your own pain first. Itamar’s team was already solving these problems for consulting clients. The product emerged naturally from that work.
Ship scrappy MVPs that solve real problems. Don’t wait for perfection. A Grafana dashboard and some scripts that actually work beats a theoretically perfect system that doesn’t exist.
Iterate based on customer feedback. Each customer who came through the door taught them something. That feedback loop was more valuable than any product roadmap.
Hire problem-solvers, not specialists. The best early team members were people who could handle anything, not people who were narrowly excellent at one thing.
Accept that perfection is the enemy of progress. There are still suboptimal pieces of code running in production. That’s okay. The alternative is never shipping.

NeverBlink’s path to $1M ARR in 18 months wasn’t about having the perfect product or the perfect plan. It was about solving urgent problems for real customers, learning from every interaction, and building a team that could execute faster than the competition.

Want to hear the full story? Listen to Itamar Syn-Hershko on Code Story to dive deeper into how he navigated the shift from consulting to product, the hiring decisions that shaped NeverBlink’s culture, and what’s next for AI-powered database reliability. Tune in now.