At Payflow, our largest customer was a regional bank — 22% of ARR, three-year contract, logo on the website. They asked for on-prem deployment. We were cloud-only. They asked harder.
The request seemed simple: a custom workflow for their AP team. Under the hood it meant forking our core payment routing logic. Engineering estimated 8 weeks. I knew it would be 8 weeks plus permanent maintenance tax.
We said no. They threatened to churn. Six months later they renewed at a higher ACV without the feature.
The concentration problem
Any customer over 15% of revenue isn’t a customer — they’re a shadow board member. One “small favor” becomes a roadmap item. One escalation becomes a QBR crisis.
We should have diversified sooner. That’s the boring lesson. The harder lesson is how to say no without torching the relationship.
How we said it
We didn’t hide behind policy. We explained tradeoffs in their language:
- Custom routing = delayed platform upgrades for them and everyone else
- On-prem = security patch burden they’d inherit
- Alternative: config layer we could ship in 12 weeks that solved 80% of the use case
We put it in writing. Their ops lead respected it. Procurement didn’t for a while.
Custom request decision tree
- Does it benefit ≥3 other customers? If yes, productize. If no, continue.
- Does it fork core architecture? If yes, default no.
- Can we charge 2x implementation cost + annual maintenance? If no, no.
- Would we want 5 more customers like this? If no, no.
When we did say yes
A different enterprise customer wanted SSO and audit logs. Half our pipeline asked for the same. We built it, priced it in enterprise tier, raised ACV across the segment.
The difference: platform capability vs. customer exception.
Aftermath
The bank stayed. We hired an enterprise AE and capped any new logo at 10% of ARR contract value. Concentration is a risk metric, not a bragging right.
Your biggest customer will ask for things. The answer isn’t always no. But the default yes is how products die by a thousand custom commits.