You're paying for seven subscriptions, using a third of each, because nobody ever agreed on how the pieces should connect.

Every SaaS platform started as one thing. Salesforce was a CRM. HubSpot was email marketing. Notion was a note-taking app.

Then they grew. They absorbed features. CRM added marketing automation. Email marketing added a CRM. Note-taking added databases, wikis, project management, and something resembling a small operating system.

The standard explanation is "platform dynamics." Network effects. Switching costs. Ecosystem lock-in. Everything composable SaaS was supposed to dissolve.

But there's a simpler, uglier truth underneath.

The Dirty Secret of Platform Growth

You're an indie hacker or a small team. You've picked your tools carefully. CRM here, analytics there, billing over here, support tickets in that corner. Five tools, five logins, five data formats, five APIs that almost talk to each other. (The average company runs over 100 SaaS apps. You're getting off easy.)

So you paste them together with Zapier. You build custom integrations that break every time one provider ships a new API version. You export CSVs and reimport them like it's 2004.

Eventually, one of those tools offers "the full suite." It's worse at three of the five jobs, but at least it's one thing. You migrate. The platform won on simplicity alone. The glue was killing you.

That's the dirty secret. Platforms don't necessarily win because they're superior. They win because composing your own stack from specialized tools is unbearably painful. Every platform is a workaround for missing standards.

A Problem Older Than Software

Before standardized shipping containers, every port had its own loading system. Cargo got unpacked, repacked, and unpacked again at every stop. In 1956, hand-loading loose cargo cost $5.86 per ton.

Malcolm McLean didn't build a better ship. He standardized the box. One size. Standard corners. Any crane, any truck, any port. Cost dropped to 16 cents per ton.

Before MIDI in 1983, your Roland synth and your Yamaha drum machine existed on separate planets. Each manufacturer had proprietary connections. Musicians couldn't compose systems from pieces they chose. MIDI fixed that with a simple protocol: here's how instruments talk. Suddenly the entire electronic music ecosystem became composable.

Before lens mount standards, photographers were locked to one manufacturer's glass. Adapters existed, but every adapter was a compromise. Some mounts opened up (M42, Micro Four Thirds), and the moment they did, an ecosystem of specialized lens makers exploded. The camera body became a commodity. The glass became the differentiator.

The structure is identical every time. Fragmented proprietary systems. Mounting pain. Then someone standardizes the connection point, and composition becomes trivial. Not better products. Just agreement on how pieces touch.

What makes the pattern useful isn't any single example. It's that the resolution is structurally identical across domains that share nothing else in common. Shipping has nothing to do with music has nothing to do with photography. But the coordination failure looks the same, and the fix looks the same: someone stops trying to build a better product and instead standardizes the connection point. Once you see the shape repeating across enough unrelated domains, you stop asking whether SaaS will get its container moment and start asking what's delaying it.

Why SaaS Missed Its Container Moment

So why hasn't SaaS had its shipping container moment? We've had APIs for twenty years. REST, GraphQL, webhooks. Why are we still in the patchwork-glue phase?

Because APIs solve the connectivity problem. They don't solve the meaning problem. Salesforce stores organizations in an Account object with a field called Name. HubSpot stores the same concept in a Company object with a field called name. People? Salesforce's Contact has FirstName. HubSpot's Contact has firstname. Same entities, different structures, different naming, different relationship models. Your analytics tool needs a custom adapter for each. Multiply that across twenty tools and you have a mapping problem that compounds with every new integration you add.

An API says "here's how to ask me for data." A protocol says "here's what a customer record IS, structurally, regardless of who you're asking." The difference is the difference between translating every conversation in real time versus everyone already sharing the same vocabulary.

Microservices was supposed to fix this. Decompose software into small services connected by APIs, and composition becomes trivial. It fell short, for more reasons than any single article can cover. But the most fundamental one is the same: better connectivity, same meaning problem.

Real protocols require consensus. And consensus is where application-level software standards go to die. W3C and IETF gave us HTTP, TCP/IP, HTML. But those are plumbing standards. They took ages too (HTTP/2 arrived 16 years after 1.1), but plumbing can afford to be slow because it rarely needs to change. Application semantics can't afford that pace. What a "customer" means, how a "subscription upgrade" is structured, what fields belong on a "support ticket," these shift with every business model pivot. A committee that takes years to agree on an application-level spec produces something that's already outdated by the time it ships. The result often satisfies nobody and arrives after the market has already chosen a winner (usually a platform that locked everyone in while the committee deliberated).

MIDI took 37 years to get a version 2.0. The first version was good enough that musicians lived with its limitations for nearly four decades rather than endure another standards process.

Standards lose because they move at human-coordination speed. Platforms win because they move at company-execution speed. The bottleneck was never technology. It was the cost of getting people to agree.

The Protocol Designer That Doesn't Need a Committee

But the problem runs deeper than speed. A committee-designed protocol is a snapshot of meaning, frozen the moment everyone agreed. Application-level meaning doesn't sit still long enough for a committee to capture it. By the time the snapshot ships, the thing it captured has moved. Faster design alone wouldn't fix this. What changes the equation is protocols cheap enough to revise, not just cheap enough to create.

AI can simulate how two systems would interact. It can propose a protocol, test it against edge cases, refine it, and propose again. Not in months of committee meetings. In hours.

Here's what that looks like concretely. Your billing system emits events like subscription_upgraded with fields for plan tier, effective date, annual revenue impact. Your analytics system expects events shaped like revenue_change with fields for amount delta, attribution source, time window. Today, you'd write a custom transformer, or Zapier would maintain a hard-coded adapter for each pair of tools. An AI protocol negotiator does something different: it reads both schemas, proposes an intermediate event shape that both systems can emit and consume natively, tests whether it handles edge cases (prorated upgrades, downgrades, trial conversions), and iterates until the contract works cleanly. The providers adopt the negotiated schema. Now any billing tool that speaks this protocol composes with any analytics tool that does. No adapter. No custom glue.

The Lego metaphor for composable software has always been aspirational. But Lego works because every brick has the same stud size, the same socket depth, the same tolerance. That's not a feature of the bricks. That's a feature of the protocol beneath them.

AI could design that protocol layer for software. It's faster than any committee. And because the coordination cost drops to near-zero, protocols can iterate quarterly instead of ossifying for 37 years. Standards that move at the speed of software, not the speed of consensus.

The Brick Maker's Edge

There's a popular question making the rounds: is AI replacing SaaS? That framing misses what's actually happening. AI isn't replacing your tools. It's designing the connections that let you replace your platform with something better: a stack you actually chose.

If composable SaaS becomes real (through AI-designed protocols, not committee consensus), several assumptions flip:

  1. You don't need to become a platform. Build the best brick. Nail one job. If your CRM module snaps perfectly into any stack, you don't need to also build billing, analytics, and support.
  2. Lock-in shifts form. You stay with Salesforce today not because you love it, but because leaving means rebuilding twelve integrations. That's the moat. In a composable world, you swap the CRM brick without touching anything else. You stay because the tool is genuinely best, not because escape is expensive. The lock-in doesn't disappear. It migrates from switching cost to quality.
  3. The customer becomes the architect. Instead of choosing a platform and living with its opinions about everything, you assemble your own system from the best specialized pieces. The way a photographer builds a camera system from bodies, lenses, and accessories that share a mount standard.
  4. Small and focused becomes structural advantage, not limitation. Indie hackers are better at building one exceptional thing than mediocre everything. In a composable world, that's exactly what wins.

The Trap Inside the Promise

There's a version of this future that's worse for indie hackers, not better.

If composability makes switching trivial, it also makes competition brutal. Today, a mediocre CRM survives because its users are locked in. Tomorrow, a mediocre CRM dies in a quarter because swapping it costs nothing. "Best brick" sounds empowering until you realize that "best" is now contested every single day by every competitor who also builds one clean brick that snaps into the same protocol.

And point 3, "the customer becomes the architect," carries an assumption worth questioning. Most customers don't want to be architects. They want someone to make the decision for them. That's half the reason platforms won in the first place. Not just the glue problem, but the decision problem. One vendor, one opinion, one throat to choke.

In a fully composable world, who curates the stack? Who tells the non-technical founder which five bricks to combine?

That's not a hole in the thesis. That's a hidden opportunity. Stack curation is a job that doesn't exist yet because it doesn't need to, platforms bundle the decisions for you. The moment composability unbundles the stack, someone needs to help people reassemble it. That's a new kind of service, maybe a new kind of role entirely. Think of it like interior design for software: you could furnish the apartment yourself, piece by piece, or you could hire someone who knows which pieces compose well together and why. Today that person doesn't have a title. In a composable world, they might be more valuable than any individual brick maker.

The interesting question isn't "do platforms die?" It's: does the bundle become less sticky when any individual brick can be swapped without collateral damage?

The Conductor (Sometimes)

A platform isn't just a bundle of tools. It's also the thing deciding what happens when, and in what order. Unbundle the tools, and that coordination work doesn't vanish.

In a composable world, do you even need a central coordinator?

For simple connections, no. If your CRM fires a lead_converted event and your email tool subscribes to it and sends an onboarding sequence, nothing needs to sit between them. Each brick handles its own reactions. That's choreography, and in a protocol-standardized world, most simple connections will work this way.

A conductor earns its place at complexity thresholds. "If lead value is over $10k AND they came from an enterprise channel, pull their usage data from analytics, check credit from billing, schedule a call in calendar, notify the account owner, but only if the credit check passed." Which brick owns that logic? It spans five systems. Cross-cutting logic that belongs to no single brick needs somewhere to live.

Zapier today is mostly translation, maintaining thousands of custom adapters because tools don't share a schema. In a composable world, that translation layer disappears. What remains is pure orchestration: the business logic of when, why, and in what order.

And here's where AI plays a second role in this story.

The first role was designing the protocols. The second is powering the conductor itself. A rule-based orchestrator executes what you told it. It doesn't reason. An AI-powered conductor handles exceptions with judgment. It notices that a certain workflow always fails on Fridays and suggests a reroute. It infers from your operation's patterns what logic you probably need, without you pre-defining every rule.

The conductor doesn't replace any brick. It orchestrates them. And because it touches every workflow, it builds a picture no individual brick can see. Everyone owns their slice. The conductor owns how the whole operation moves, and adapts when circumstances shift.

This might also be the answer to the "who curates the stack?" question from the section above. The conductor isn't just an orchestrator. It's the thing that removes the architect burden from the user. "Here's what you're trying to accomplish. Based on your patterns, here are the bricks and connections that serve it." Composability for builders, curation for everyone else, same underlying protocol layer.

Two Forces Pushing Back

This isn't inevitable. Two pressures resist it.

First, incumbents have zero incentive to participate. Salesforce doesn't want you composing your own CRM from three specialized tools that each do one job better. Platform lock-in is their business model. They'll adopt composability language without offering composability substance.

Second, AI-designed protocols still need adoption. A brilliant standard that nobody implements is just a PDF collecting dust. Providers won't adopt until customers demand it, and customers can't demand what doesn't exist yet. Classic chicken-and-egg.

But pressure builds from the other direction. Every founder who migrates to a worse-at-everything platform because the glue was killing them represents stored demand. Every Zapier workflow that breaks at 2 AM is a vote for real composability.

The question isn't whether composable SaaS is desirable. Everyone with seven subscriptions already knows the answer. The question is whether the coordination problem finally has a solvent.

For the first time, it might. The competition will be fiercer, the curation problem is real, and the incumbents won't go quietly. But here's what's different now: the cost of designing agreement dropped by orders of magnitude. That was always the first bottleneck. Not technology. Not desire. Just the grinding expense of getting people to agree on how pieces should touch. AI doesn't force adoption, but it removes the excuse that standards take too long to design and iterate. When a protocol can be proposed, tested, and refined in days instead of years, the political cost of resistance becomes harder to justify.

Build the best brick. The sockets are coming.

Rabbit Hole