My team came to me with a customer request, a rough spec, and the kind of confidence that comes from knowing exactly how long something will take to build.
"We can vibe-code this in no time," they said. "And if we build it ourselves, we can integrate it directly with the core product — better insights, cleaner analytics, the full picture."
It was a good argument. They weren't wrong.
I still said no. Not "let's evaluate it." Not "let's put it in the backlog." Just no.
A customer had recently asked us for more functionality in the way they interact with our customer support team. They wanted a better dashboard, clearer tracking, more analytics, and easier access to updates on the topics they cared about.
The request was reasonable. The customer support platform we were using had limitations, and it was not meeting all of their expectations.
My team's response was also reasonable. After all, this is 2026. We could vibe-code most of what the customer wanted, connect it to our existing systems, and release something surprisingly capable in very little time.
Can you guess my response?
No.
The real question is not whether we can build it
The cost of building software has fallen dramatically.
What once required months of engineering effort can now be prototyped in days, sometimes hours. That changes the economics of product development — but it does not eliminate the need for product strategy.
In fact, it makes product discipline even more important.
When building becomes easier, teams become more likely to build things simply because they can.
But the real cost of a feature is rarely the initial development effort. The real cost is everything that happens after launch:
- Customers begin depending on it.
- Customer Success begins positioning it.
- Feedback starts arriving.
- Bugs need to be fixed.
- Integrations need to be maintained.
- Reporting requirements expand.
- One customer's workflow becomes another customer's expectation.
- A temporary solution quietly becomes part of the product.
Vibe coding compresses development time. It does not eliminate product ownership.
We are trying to reduce support involvement, not improve it
Today, more than 90% of the travel we serve is handled directly by the product. Our customer support team becomes involved in less than 10% of transactions. And my long-term goal is to bring that number as close to zero as possible.
Realistically, it will never reach absolute zero. Travel is unpredictable. Flights get cancelled, hotels lose reservations, suppliers fail, and unusual situations will always require human judgment.
But strategically, the direction is clear: every recurring support interaction should be treated as an opportunity for the product to become better.
That is why building a sophisticated customer-facing support dashboard felt wrong. It would make the support process easier to observe and manage. But it would not reduce the customer's need for support. We would be building a better interface for a workflow we are actively trying to minimize.
I would rather have my product and engineering teams investigate why customers need those updates in the first place.
Can the product detect the issue earlier? Can it resolve the issue automatically? Can it proactively notify the traveler or travel manager? Can we eliminate the uncertainty that makes the customer ask for a status update?
Those are harder problems. They are also the problems that move our product forward.
Every feature creates a constituency
Once we build something, it becomes very difficult to treat it as temporary.
The customer understandably assumes: we built this, therefore we own it. The next request might be a new filter. Then a different report. Then customized alerts. Then role-based permissions. Then integration with another system. None of these requests will sound unreasonable.
Customer Success managers will also advocate for them — and they should. Their responsibilities include customer satisfaction, retention, and helping customers get value from the platform.
But this creates a predictable internal dynamic. The customer sees an incomplete product. Customer Success sees a retention risk. Engineering sees something that can be implemented quickly. And gradually, an internal support utility becomes a roadmap competing for product investment.
This is not because anyone is making a bad decision individually. It is because each team is responding rationally to its own incentives. Product leadership has to protect the company from the cumulative effect of those individually rational decisions.
Listening to customers does not mean building what they request
The customer's request was valuable. It told us that they lacked visibility, confidence, and control when an issue required support intervention.
But a customer request contains two different things:
- The underlying problem.
- The customer's proposed solution.
We should take the problem extremely seriously. We do not always have to accept the proposed solution.
Customer obsession is not the same as request fulfillment.
Sometimes the most customer-centric decision is to build exactly what the customer asks for. Sometimes it is to solve the underlying problem differently. And sometimes it is to use an existing third-party tool rather than turning a supporting workflow into a proprietary product.
That is what we chose to do. We selected a customer support platform that could provide the dashboards, analytics, tracking, and communication capabilities the customer needed. We will clearly communicate what the platform offers. But we are not creating a custom product roadmap around it.
Buy the commodity. Build the differentiation.
This decision reflects a broader product principle: buy the capabilities that help you operate. Build the capabilities that make you different.
A better support dashboard might improve the experience of managing exceptions. A better travel product reduces the number of exceptions. Only one of those strengthens our core differentiation.
AI-assisted development makes it tempting to build both. But having the ability to build more things does not mean a company should own more things.
The easiest feature to build can become the hardest strategic decision to unwind.
So yes, we could have vibe-coded the requested functionality. We chose not to.
Because the goal is not to build software faster. The goal is to build less of the wrong software — and direct our energy toward making customer support progressively less necessary.
Originally published on LinkedIn. View the original →