Martech stopped growing this year.
The 2026 landscape counts 15,505 solutions, up 121 from last year’s 15,384. That’s 0.79% growth after a decade of double digits. Underneath the flat number there’s enormous churn: about 1,488 products added, about 1,367 removed. Scott Brinker and Frans Riemersma call it martech’s Darwin phase. More than half the departures came from the 2010 to 2019 SaaS wave, and the mid-market is getting squeezed between incumbents bundling everything and AI-native startups unbundling it.
For years the argument for composability was about abundance. Too many options, so build a stack you can rearrange.
That argument is over. The new one is more interesting, and it changes what you should buy.
The Suite Was Always a Bet About Integration Cost
Every all-in-one purchase comes down to the same trade. You accept constraints on capability in exchange for integration you don’t have to build.
That was defensible when integration was expensive. Connecting a best-of-breed testing platform to your CDP and your warehouse and your email tool meant engineering time you didn’t have, a schema mapping exercise nobody wanted to own, and a maintenance burden that appeared every time a vendor changed an API. The suite’s pre-built connections were worth real money because building them yourself cost real money.
So companies bought the suite. Then spent three years discovering which components they’d never have chosen on their own.
What AI Changed
The cost of interfacing between systems dropped, faster than most stack decisions have caught up with.
Schema mapping used to be a discovery project. Now it’s something you draft in an afternoon by pointing a model at both schemas and reviewing what it proposes. Transformation logic that took a week is a first draft in an hour. API documentation that needed a specialist is something a competent marketer can work through with assistance. The glue code between a workflow tool and an unfamiliar endpoint is no longer the bottleneck.
Agent-mediated tool access pushes this further. When systems expose their capabilities in a standardized way a model can call, integration work moves from custom code per connection toward configuration and permission design. That shift is early and uneven across vendors, and it’s real enough to plan around.
Add it up and the suite’s central value proposition weakened. You’re still paying the constraint cost of the all-in-one. You’re getting less in return, because the thing it was saving you from got cheaper.
Cheaper doesn’t mean free, automatic, or low-risk. Production integration still requires authentication, permissions, testing, observability, error handling, change control, documentation, and someone who can support the connection after launch. The point isn’t that integration disappeared as a cost. It’s that integration is less often the dominant reason to accept a tool’s constraints without examining the alternatives.
What AI Didn’t Change
This is the part skipped in the pitch, and the part that determines whether any of it works.
AI can generate the connector. It cannot decide what “customer” means in your business.
It can map a field from one system to another. It can’t tell you the two systems define an active account differently, that one excludes trials and the other doesn’t, and that reconciling them is a business decision somebody has to make and document.
It can write transformation logic quickly. It can’t tell you whether the data going through it was collected under terms permitting this use.
It can connect two tools in an afternoon. It can’t tell you whether connecting them creates a compliance exposure, a circular dependency, or a system nobody can explain in six months.
Every one of those is a definition, a decision, or an ownership question. The same ones as 2019. The cost of the plumbing went down. The cost of getting the semantics wrong went up, because now the wrong semantics propagate through automated workflows at a speed no human reviews.
Choose the Move Before You Choose the Tool
Before treating a suite renewal or a new AI capability as a product decision, decide which kind of decision it is.
| Move | Choose it when | Watch for |
|---|---|---|
| Buy | A proven product fits a defined workflow and your team can operate it | Paying for capability you won’t use, or letting the product become the only place critical business logic lives |
| Build | The capability is central to your advantage, requirements are specific, and you can maintain it | Writing custom software for a problem a mature product already solves |
| Connect | Existing tools can solve it if data, handoffs, permissions, and ownership are reliable | Brittle integrations with no monitoring, error process, or named owner |
| Skip | The workflow, data, owner, or success measure is unclear | Buying software to avoid diagnosing the problem |
The fourth option is underrated. “Not yet” saves teams from expensive detours disguised as roadmaps.
Own the Place Where Data Gets Stitched Together
If integration is cheap and definitions are expensive, the thing worth owning is the layer where definitions live.
One place where your customer data gets unified, where a field means one thing, where identity resolution logic is explicit, and where you can name the source of truth without a meeting. A warehouse, a CDP, a data layer, or a combination, depending on what you already run.
Vendor-neutral doesn’t necessarily mean self-hosted, custom-built, or centralized in one product. It means the organization can access, understand, govern, export, and migrate the definitions and history that make the business intelligible. Identity rules, event definitions, consent states, campaign taxonomy, and critical metrics shouldn’t exist only as opaque configuration inside one application. For one company that coordination layer is governed warehouse data. For another it’s a well-maintained CRM, event pipeline, or integration layer. Architecture should follow the use case and the operating capacity rather than a fashionable reference diagram.
The real unit of composability is the interface. For every connection that matters, document what moves between systems, what each critical field means, which system is authoritative, what triggers the handoff, how errors get detected, who owns it, and what happens when a vendor changes an API or a consent rule changes.
That’s a data contract. It doesn’t need to be elaborate. It needs to exist somewhere other than the memory of the person who built the workflow.
A stack isn’t composable because it has APIs. It’s composable when you can change one part without losing the meaning, history, permissions, and operating knowledge attached to the connection.
Four Risks Worth Naming
Generated connector code still needs an owner. A model writes an integration in an hour. Somebody still has to understand it, test it, and fix it at 11pm when the vendor changes a field. Code you didn’t write and don’t understand is technical debt regardless of what produced it.
The standard isn’t that every marketer explains every line. It’s that the organization has a named technical owner, accessible documentation, test coverage matched to the consequence of failure, monitoring for breakage, and a recovery path. AI-generated code lowers the cost of starting. It can raise the cost of operating if it lets teams create more connections than they can maintain.
Easy connection makes governance harder. When connecting two systems required a ticket and an engineer, the friction was accidental governance. It slowed things down and created a checkpoint. Remove the friction without replacing the checkpoint and nobody can produce an accurate diagram of what’s connected to what.
Replace accidental governance with deliberate, light controls: a named owner before a connection goes live, a documented purpose and data flow, least-privilege access, an approval path for sensitive uses, monitoring for failed handoffs, and a periodic review of whether the connection still serves a real need. The goal isn’t a ticket queue for every low-risk workflow. It’s making sure speed doesn’t outrun your ability to explain, repair, or retire what you connect.
The tool you plug in may be gone next year. Composability is the defense, and it works only if you kept the coordination layer neutral instead of letting the newest tool gradually become the place where definitions live.
Bundling is a real counter-move. Incumbents are folding AI capabilities into the suite at prices that make standalone tools hard to justify. Sometimes the suite is the right answer. Choose it because it wins on merit rather than because rearranging felt too expensive.
License Cost Is the Visible Part
Every additional tool can add authentication, permissions, monitoring, data-quality checks, security review, access management, training, documentation, incident response, vendor-change work, and support.
AI reduces implementation effort. It doesn’t eliminate operating responsibility after launch. A connector that takes an hour to draft can still become an undocumented dependency costing a team days every quarter.
Count the work before declaring a tool cheap. The cost of a stack is the subscription total plus the people required to make it reliable.
How I’d Decide
| Question | What a concerning answer reveals | What to do next |
|---|---|---|
| If we removed this tool in eighteen months, what leaves with it? | Definitions, identity logic, history, consent states, or reporting logic live inside a vendor you can’t readily replace | Identify which business rules must be extracted, documented, or made portable before renewal |
| What does this tool do that we couldn’t reach through the layer we already own? | “Integration depth” may be standing in for a capability claim untested against current implementation cost | Compare differentiated capability, total operating cost, and implementation risk against a connection you could maintain |
| Who owns the connection after it exists? | You reduced build effort by creating an unowned future liability | Assign an owner, support path, monitoring approach, and review cadence before launch |
| How do we exit if the vendor, pricing, API, or consent rule changes? | The team treats adoption as reversible without having designed for reversibility | Define export, migration, and retirement requirements before dependence deepens |
If the honest answer to several of these is “we aren’t sure,” the next investment is discovery and design rather than another subscription.
Start With One Workflow
Don’t begin by diagramming every tool in the company.
Choose one high-value workflow: lead capture to CRM, product event to customer communication, attribution to reporting, or an AI-assisted workflow that reads from and writes to business systems. Map the applications, identifiers, fields, handoffs, permissions, owners, failure modes, and downstream actions. Then ask which parts are portable, which are undocumented, and which would be difficult to replace.
The first useful deliverable usually isn’t a future-state architecture. It’s an honest map of the dependency you already have.
The Short Version
The landscape stopped expanding and started turning over. Integration got cheap. Definitions got expensive.
Own the layer where meaning lives. Rent everything else.
Before the Renewal Conversation
Suite-versus-composable is a decision with a date on it, usually a renewal date, and usually less time to think than it deserves.
A Working Session is 90 minutes on that one decision: what you’d be giving up, what you’d own instead, and what has to be true first. The fee is credited against a Diagnostic if you book one within 30 days.
