The Composability Trap

The Siren Song of "Best-of-Breed"

The narrative sounds bulletproof:

"We don't want to be locked into a monolithic vendor. We want flexibility. We want to pick the best tool for each job. Best-of-breed wins."

Every SaaS pitch deck echoes this. Every CTO who's been burned by a heavyweight enterprise suite nods along. The promise is seductive: compose your own stack from the world's best components and outperform the all-in-one players.

Then reality arrives.

You have 40 integrations. None of them talk to each other properly. Your data model is fractured across 12 systems. Your onboarding flow touches 7 different APIs, and when one times out, the whole thing falls apart. Your ops team spends half their time just keeping the pipes connected.

Welcome to the Composability Trap.

The Promise vs. The Tax

Composability is beautiful in theory. It mirrors how Unix was designed: small tools, sharp edges, connected by pipes. Each program does one thing well. Combine them into something powerful.

But here's what the Unix philosophy didn't have to deal with:

• Network latency — stdin/stdout is instant; HTTP round trips are not
• Authentication sprawl — OAuth scopes, API keys, token refresh logic, per-service permission models
• Schema drift — every vendor changes their data model independently, breaking your glue code
• Version hell — service A updates, breaks integration with service B, but service C depends on the old behavior
• Observability fragmentation — logs in Datadog, metrics in Grafana, traces in Honeycomb, errors in Sentry—good luck debugging cross-service failures

Each integration adds surface area. Not just technical surface area—organizational surface area. Someone has to own the Salesforce-to-Slack connector. Someone has to debug why the Stripe webhook stopped firing. Someone has to update the Zapier workflow when the API changes.

This is the Composability Tax, and it compounds faster than people expect.

The Tipping Point

Early on, composability is a superpower. You move fast because you're not building everything from scratch. Stripe handles payments, Auth0 handles identity, Twilio handles SMS. You glue them together and ship.

But there's a tipping point—usually somewhere between 15-30 integrations—where the tax starts exceeding the value. The integrations become the product. Your engineers spend more time on glue code than core logic. Onboarding a new team member means handing them a Miro board that looks like a circuit diagram.

At Link11, we hit this wall hard around 2012. We were composing best-of-breed security tools—firewalls, IDS, traffic analyzers, threat feeds. Each one was technically superior in isolation. But orchestrating them in real-time during a DDoS attack? Brutal. The integration latency alone cost us response time we couldn't afford to lose.

We consolidated. Built more in-house. The operational complexity dropped 10x. We could move faster because we controlled the whole stack.

When to Compose

Composability isn't bad—it's just situational. Here's when it works:

1. Non-Critical Paths

If the integration failing doesn't break your core product, compose freely. Marketing analytics? Email campaigns? Support ticket routing? These are great candidates for best-of-breed stitching. Downtime is annoying, not catastrophic.

2. Commoditized Functions

Don't build your own auth, payments, or email delivery. These are solved problems. The integration cost is worth it because the alternative (building and maintaining your own) is far worse.

3. Early Exploration

Pre-product-market-fit, you don't know what you're building yet. Composability lets you experiment without overcommitting. Swap tools fast, test hypotheses, stay nimble. Just know you'll pay the tax later if you succeed.

4. When You Have Leverage

If you have the engineering depth to build robust abstractions, composability becomes sustainable. Netflix can compose because they built Eureka, Hystrix, and a whole ecosystem of glue. Most startups can't—and shouldn't try.

When to Consolidate

Consolidation makes sense when:

1. The Integration Is in the Hot Path

If a third-party API call sits in your critical user flow, you've handed over control of your latency and uptime. Stripe outage = your checkout is down. Twilio rate limit = your 2FA is broken. Bring it in-house or accept the dependency risk.

2. The Vendors Don't Talk

If you're constantly writing glue code to translate between incompatible data models, you're fighting the wrong battle. Consolidate into a platform that owns the data model end-to-end.

3. The Tax Exceeds the Benefit

When your team spends more time fixing integrations than shipping features, the math has flipped. Rip out the duct tape and build it yourself—or find a single vendor that does 80% of it.

4. You Need Deep Customization

Off-the-shelf tools are great until you need something they don't offer. APIs and webhooks only go so far. If you're hacking around limitations constantly, you've outgrown the tool. Build what you need.

The Pragmatic Middle Path

The real answer isn't "always compose" or "always consolidate." It's knowing which parts of your stack need tight integration and which can stay loosely coupled.

Here's the heuristic I use:

Compose at the edges. Consolidate at the core.

Your core product—the thing that differentiates you—should be tightly integrated, ideally in-house. This is where you need speed, control, and reliability. Your edges—marketing tools, support systems, analytics dashboards—can be best-of-breed and loosely coupled. If they break, your product still works.

Think of it like a cell. The membrane is permeable—things flow in and out. But the nucleus? That's locked down, tightly controlled, because it's mission-critical.

The Future: Platforms Eat Composability

Here's the trend I'm watching: every major platform is absorbing its ecosystem.

Notion used to integrate with Airtable. Now it has built-in databases. Slack used to rely on bots for workflow automation. Now it has Workflow Builder. ChatGPT used to need Zapier for actions. Now it has native plugins and function calling.

The composability window is closing. Platforms realize that integrations are friction, and friction is where users churn. So they're building the features in-house, optimizing the hell out of them, and obsoleting the third-party tools.

If your product strategy is "best-of-breed integration hub," you're on borrowed time. The platforms you're gluing together will eventually glue themselves.

The Bottom Line

Composability is a tool, not a religion. Use it when it gives you leverage. Abandon it when it becomes a liability.

The best systems I've seen aren't purely composed or purely monolithic. They're strategically consolidated—tight integration where it matters, loose coupling where it doesn't.

If you're drowning in integrations, ask yourself:

• Which of these are in my critical path?
• Which of these could I replace with 500 lines of code?
• Which of these am I keeping because "best-of-breed" sounds smart?

Then consolidate ruthlessly.

Your future self—and your ops team—will thank you.