When Nobody Wants Your Product
The Moment We Realized CI Optimizer Was Doomed
In the first part of this series, we introduced CI Optimizer, a product we were convinced would help engineering teams reduce their CI/CD costs. Given the economic downturn in 2023, we saw budgets tightening, companies folding, and engineering teams being forced to justify every dollar they spent.
If you missed the first part, read it below:
It seemed like the perfect time to launch a tool that would bring cost visibility and optimization to CI/CD workflows.
We started building immediately, setting up a landing page and a waitlist, and running early customer interviews. Our approach was clear:
Build the product.
Talk to potential users.
Iterate based on feedback.
But as we reached out to customers, one thing became clear:
💡 Nobody really cared about optimizing CI/CD costs.
This was the moment we realized we were building something that might never find an audience.
Trying to Sell the Product Before It Existed
I strongly believe that you should be selling a product before it even exists. If you can’t generate demand when it’s just an idea, chances are you won’t generate demand once it’s built.
So, as we were writing the first lines of code, we also launched:
✅ A marketing campaign to build awareness.
✅ A landing page with a waitlist.
✅ Customer outreach to gauge interest.
Our goal was to validate demand early—before we wasted months building something nobody wanted.
But things didn’t go as expected.
The First Red Flag: Engineers Didn’t Care
As we started talking to users, the first warning sign was that engineers were simply not interested in optimizing their CI/CD costs.
💬 “Sure, spending less money is nice, but it’s not a priority.”
💬 “We’ve never been asked to reduce our CI/CD spend.”
💬 “CI is just a necessary cost of doing business.”
This was surprising. We expected companies to be actively looking for ways to cut costs, but instead, we found:
👉 Engineers weren’t incentivized to optimize costs. Most of them were measured by features delivered and bugs fixed, not by how much they spent on infrastructure.
👉 Budgets were tight, but existing expenses weren’t scrutinized. Many teams were cutting new expenditures, but existing CI/CD costs were just accepted as part of doing business.
👉 It wasn’t an engineering problem—it was a finance problem. Even when engineers acknowledged CI/CD spending was high, they said, “This isn’t my job to fix.”
In short:
🚨 We had built a solution for a problem our audience didn’t care about.
But we weren’t ready to give up yet.
The Second Red Flag: Talking to the Wrong People
Since engineering teams didn’t seem to care, we were often redirected to FinOps teams—the financial teams responsible for tracking cloud spend.
So we thought, “Great! Maybe this is our actual target audience.”
We started talking to FinOps teams, and here’s what we discovered:
💬 “We don’t need another tool—we just need a report in a spreadsheet.”
💬 “Can you just give us an API so we can generate cost breakdowns?”
💬 “We don’t want to ‘optimize’ CI/CD automatically. We just need visibility.”
💬 “If we were to buy your product, we’d need more than reporting. We want automatic cost optimization.”
Here’s where we ran into our second major issue:
🚨 We were not equipped to build a product for FinOps teams.
We understood engineers. We had deep experience with CI/CD workflows.
But we knew nothing about selling to FinOps.
Selling to FinOps teams is a completely different game.
They care about budgets, forecasting, and high-level cost reporting, not about how CI/CD actually works.
Even worse:
❌ The product we had in mind was too technical for FinOps teams.
❌ The version they needed was much more complex and would take a year to build.
❌ We would be competing against massive cloud cost monitoring tools, not other DevOps tools.
At this point, we had two choices:
Keep building a product for engineers who didn’t care.
Completely pivot to a new audience we didn’t understand.
Neither option looked good.
The Hard Decision: Killing the Product
By the six-month mark, we had spent:
🕚 Hundreds of hours building a proof-of-concept.
📞 Countless customer calls trying to validate the idea.
💬 Weeks refining our messaging to see if we could spark interest.
But deep down, we knew the truth:
❌ Engineers wouldn’t pay for cost optimization.
❌ FinOps teams needed something completely different.
❌ There was no clear path forward.
And so, after six months of work, we made the hardest decision a product team can make:
We killed the project.
Instead of pushing forward with a product that had no market, we pivoted to something else—which I’ll reveal in the final part of this series.
Lessons Learned
Even though we ultimately abandoned CI Optimizer, the experience taught us some critical lessons about building new products:
Talk to Customers Before Writing Code
We should have validated demand before starting development. Building first and testing later is a risky approach. Fortunately we mitigated this by talking while building.
Engineers Don’t Always Care About Cost Savings
Developers are focused on shipping code, not cutting costs. If a product doesn’t directly impact their work, they won’t engage with it.
Just Because a Problem Exists Doesn’t Mean It Needs a Product
Companies do spend too much on CI/CD, but that doesn’t mean they’re looking for a tool to fix it. Some problems are simply not painful enough to justify a new product.
Selling to Finance Teams is a Whole Different Game
FinOps teams think differently from engineers. If your product doesn’t fit into their existing finance workflows, they won’t use it.
Know When to Walk Away
One of the hardest skills in startups is knowing when to cut your losses. We could have wasted another 6–12 months building something nobody wanted. Instead, we chose to fail fast and pivot.
What’s Next?
Even though CI Optimizer never launched, it wasn’t a wasted effort.
In fact, the insights we gained from this failure led us to build something even better.
In Part 3, I’ll reveal how we took everything we learned from this failure and pivoted to a product that actually resonated with engineers—and how that decision changed the trajectory of Mergify.