Jonathan Haaswritingnowusesabout
emailgithubx
Jonathan Haaswritingnowusesabout

The Integration Tax: What Nobody Tells You About Building Modern Software

April 11, 2024·2 min read

Every integration you add is a long-term commitment you're not budgeting for. The technical implementation is the easy part.

#engineering#product#strategy#infrastructure

Every integration you add is a long-term maintenance commitment you're not budgeting for. Teams plan for the build -- typically days to weeks -- then ignore the ongoing cost of keeping that integration alive. The implementation is the cheapest part.

How the Tax Compounds

We once spent three weeks updating our codebase because a critical auth provider deprecated their v1 API. Three weeks of zero feature work, purely keeping the lights on. That deprecation didn't just affect auth -- it cascaded into every service that consumed user tokens, which was effectively the entire system.

The tax compounds across three dimensions.

Lifecycle management. Every integration requires monitoring, version tracking, and eventual replacement. Most teams budget for none of this. The Jira ticket says "integrate X" with a two-day estimate. The five years of maintenance never appear on any roadmap.

Dependency cascades. A single API change triggers chain reactions. One field renamed in a vendor response broke our payment flow, our analytics pipeline, and our compliance reporting -- three systems that appeared unrelated but all consumed the same upstream data.

Knowledge debt. Each integration accumulates undocumented quirks. When the engineer who built the Braintree integration leaves, what remains is 200 lines of payment code nobody will touch, sitting next to the Stripe integration that replaced it, sitting next to the "modern" payment flow that replaced that. Three layers of integration archaeology in one directory.

The Only Viable Defense

Every codebase older than a few years has an integration graveyard: layers of abandoned connector code where each layer represents a moment someone said "we should clean this up" but couldn't justify the effort.

The defense is architectural. Build every integration with the assumption it will be replaced. Core business logic calls your abstraction layer, which calls the vendor's API. When the replacement comes -- and it always comes -- you swap the implementation without touching the architecture.

This isn't theoretical hygiene. It's the difference between a three-week fire drill and a one-day migration. The quality of your software isn't what it can do today. It's how cheaply it adapts when everything around it changes.

share

Continue reading

The Abstraction Trap: When Clean Code Goes Wrong

The most insidious form of technical debt does not come from rushed code or tight deadlines - it comes from overly clever abstractions built too early.

Quality: The Foundation of Sustainable Growth

Quality in the wrong places will kill your startup faster than no quality at all. The question is not how much quality, but quality where.

Engineering Recognition Through Evals: My Technical Journey Building Shout

Building an LLM-powered evaluation system to measure whether engineering recognition is specific, accurate, and connected to impact.

emailgithubx