The Cost of Saying Yes to Everything
A customer calls. Big deal. $500k ARR. They want a custom export feature. "Sure," you say. "We'll ship it in two sprints."
That's two sprints your team isn't spending on the roadmap you committed to. But you didn't think about it that way. You just saw an opportunity. You said yes.
Then another customer calls. Different problem. Custom integrations. You're at three sprints now of customer work. The roadmap slips. Then another request comes in. And another.
Six months later, your product looks nothing like you planned. You're a services business disguised as a software company. Your engineers are burning out. Your committed customers are frustrated because the features you promised them aren't shipping.
This is the hidden cost of saying yes.
The Math Is Brutal
Let's say you've got a four-person engineering team. 16 story points per sprint. Your roadmap has 20 points of feature work every two weeks. That's already optimistic.
Now sales closes a deal with a feature request. "Three sprints," you say confidently.
So for the next six weeks, you're shipping zero points of roadmap. But you still told your customers about the features you're building. They're waiting. Your retention is getting hammered.
Then the customer churn hits. Two customers leave. $50k ARR gone. Why? Because you shipped the custom integration faster than you shipped the thing they were actually buying your product for.
The custom feature was worth $100k. Looks like a win. Except you lost $50k in churn plus the six weeks of momentum. Plus the fact that your team's now demoralized—they spent two months on tech that only one customer uses.
Net: broke even at best. Probably negative when you account for morale.
Why We Say Yes
This is the easy trap to fall into, especially early.
You need revenue. A customer wants custom work. Your gut says "this relationship matters." So you say yes.
That was right when you were at $0. You were also right at $1M. But at $10M? At $50M? The math changes.
By the time you've got a sustainable business, custom work actually destroys value. Here's why:
It pulls engineering off the core product. Your product is what you're competing on. Every hour spent on customer-specific code is an hour your competitors are spending on being better at the core problem.
It creates technical debt. One-off integrations are messy. They're not built to scale. They're built to ship. So your codebase gets worse. Future features get slower to build.
It sets expectations. Once you build one custom feature, the next customer expects it too. Before long, you're building 20% of your product on a per-customer basis. That's not sustainable.
It kills prioritization. When sales can override the roadmap by closing a big deal, the product strategy becomes "whatever the largest customer wants." Your product has no direction. It's a patchwork of customer requests.
What The Best Teams Do
The best product teams I know have a rule: No custom features.
Not "almost no." Not "rarely." No. The answer is no unless it goes into the core product that everyone gets.
If a customer wants a specific integration, they get an API and we tell them to build it themselves. Or we build it if it's strategically important to the platform.
If a customer wants a custom workflow, we build a configuration system that works for everyone.
That's harder in the short term. You ship fewer logos. Your CRO hates you. But your product actually improves.
I worked at a company that got serious about this. They had $10M in custom work requests in the pipeline. They said no to $8M of it.
Here's what happened: ARR flatlined for a quarter. The board freaked out. Then, two quarters later, the core product was so much better that expansion revenue started coming in. Existing customers bought more because the product was actually great.
They didn't lose the $8M. They just realized it was never real revenue. It was rent, not revenue.
The Exception That Proves The Rule
There's one exception: if the custom work fundamentally changes how your product works, and it's useful for many customers down the line, you should do it.
"I built a custom integration for TechCorp, but it's now part of our platform and used by 60% of our customers"—that's not custom work. That's product development that happened to be driven by a customer.
That's different from "we built a thing for one customer that only they use."
The litmus test: If you shipped this feature, would 50%+ of your customer base eventually use it? If yes, it's product work. If no, it's custom work.
The Hard Part
Saying no feels bad. Especially when your company is young. Every customer feels important. Every deal feels massive.
But the companies that win are the ones who say no early and often. They have a product vision, and they protect it. They tell customers "that's a great idea, but it doesn't fit our roadmap." They stick to their bets.
The companies that say yes to everything end up as services businesses wondering why they can't scale. They've got 50 customers, each with different requirements, each requiring custom work, and zero leverage.
Your strategy is defined by what you say no to. The best teams in the world got there by refusing to build most of the things people asked for.
Start practicing that today.