Every feature you ship becomes a promise. Every integration you maintain is a recurring cost disguised as a one-time win. We learned this when we finally killed an integration that customers loved — and that was quietly eating our team alive.
About eighteen months ago, we added a third-party integration connecting our platform to an external service popular with a segment of our users. The request came up often enough in support tickets and sales calls that the decision felt obvious. A small team built it in a couple of weeks. Customers cheered. We moved on.
What we didn't account for: the vendor on the other side had no stability contract with us. Their API changed at their pace, not ours. Every time they shipped a breaking change, we absorbed the cost. At first it was a few hours here, a quick patch there. Normal maintenance.
Then it compounded.
Over twelve months, that single integration generated more unplanned engineering work than any other area of the product. Not because it was poorly built — the original implementation was solid. The problem was the surface area. Every upstream change forced us to react. Every reaction pulled someone off planned work. And because the integration touched real customer workflows, every regression was urgent.
We tracked three things that made the cost visible:
Interrupt frequency. Engineers were context-switching to fix integration issues roughly every two weeks. Each interrupt broke focus on whatever they were actually building.
Support load. Tickets related to this integration accounted for a disproportionate share of inbound volume. Not because our code was buggy, but because users hit edge cases every time the upstream API shifted behavior.
Opportunity cost. Features we'd committed to kept slipping. When we looked at why, a pattern emerged: the same two engineers kept getting pulled into firefighting.
None of these was catastrophic alone. Together, they painted a clear picture: we were spending ongoing capital to maintain a connection that served a fraction of our user base.
Deciding to kill it wasn't emotional. We built a simple evaluation:
Who depends on it? We looked at actual usage, not stated demand. The integration was active for a meaningful number of accounts, but most used it infrequently. Only a small subset relied on it daily.
What's the maintenance trajectory? Flat costs are manageable. Rising costs are a signal. The upstream vendor was iterating fast, which meant our maintenance burden was accelerating. No reason to expect it would slow down.
What would we gain back? We estimated the engineering hours freed up and mapped them against our roadmap. The trade was stark: keep the integration and slip two planned features by a quarter, or cut it and deliver on time.
Is there a credible alternative for affected users? Yes. The vendor offered their own direct path for the use case. Not identical to what we provided, but workable. We weren't stranding anyone.
Once we laid it out, the answer was clear. The integration had become a liability.
We gave affected users sixty days of notice and a migration guide. We offered direct support to the accounts that relied on it most. We were honest about why: maintaining this integration was coming at the expense of the broader product, and we chose the broader product.
Some users were frustrated. A few were vocal. Nobody churned — partly because we handled communication well, partly because the alternative path existed, and partly because the features we shipped the following quarter addressed needs those same users had been raising for months.
The lesson isn't "kill your integrations." The lesson is that every maintained surface area has a carrying cost, and that cost changes over time. The integration that made sense eighteen months ago didn't make sense anymore. We were slow to notice because the cost was distributed across small interrupts rather than concentrated in one visible failure.
Now we evaluate maintained surface area on a regular schedule. Not just integrations — any dependency, any feature with external coupling, any commitment that requires ongoing engineering attention. The questions are always the same: Who uses it? What's the trend line on maintenance? What are we not building because of it?
Saying yes to a feature is easy. Saying no to something that already exists and already has users — that's the harder, more important skill. Small teams can't afford to maintain everything. The discipline is in choosing what to stop, not just what to start.
If you're on a small team managing a growing product, audit your commitments. Look at where unplanned work clusters. Follow the interrupts. You'll probably find one thing costing more than it's worth — not because it was a bad decision, but because the math changed and nobody updated the equation.
Kill it. Ship something better with the time you get back.
Be the first to comment.
0 comments
Loading comments...