The Add-On Trap: When Every New Feature Creates Another Dependency

Modularity is not the problem

A modular suite can be the right architecture. A business should not have to deploy every capability at once, and specialized modules can isolate risk, permissions, and complexity. Add-ons can also extend a stable platform without forcing a complete replacement.

The problem begins when the decision is evaluated only as a feature purchase. The business asks, “Does this module do the task?” but not, “What new dependency does this task create?”

A common login, vendor name, or invoice does not guarantee one customer identity, one data model, one permission system, one reporting definition, or one lifecycle. Even products inside the same suite can preserve separate objects and require mappings, reconciliation rules, entitlements, or scheduled movement between them.

Every add-on creates a dependency surface

Before approving another module, integration, marketplace app, or AI feature, inspect seven surfaces that remain after the demo ends.

1. Data

Which new objects, fields, copies, indexes, attachments, and identifiers will exist?

2. Identity and access

Which users, service accounts, agents, roles, permission sets, and consent rules must be maintained?

3. Workflow

Which triggers, approvals, notifications, queues, and exception paths will depend on it?

4. Integration

What is copied, queried, transformed, or written—and how will failures and deletions be reconciled?

5. Meaning

Which statuses, calculations, reports, and business definitions will become platform-specific?

6. Commercial access

Which seats, tiers, usage credits, storage, API limits, connectors, and support levels are required?

7. Exit

What must be exported, rebuilt, translated, retrained, or operated in parallel if the tool leaves?

Feature value belongs on one side of the decision. The full dependency surface belongs on the other. A low-cost add-on can be expensive when it becomes the only place a critical definition, workflow, or history exists.

Why the suite can keep growing while the system gets harder to understand

Software platforms are often built around bounded objects and services. That design makes products extensible: new applications can attach to accounts, contacts, opportunities, tickets, projects, or other records. It also means every extension must decide how its objects relate to the rest of the system.

When the relationship is incomplete, the next product can appear to solve the visible symptom. A reporting add-on reconciles separate records. A workflow add-on moves data that the core applications do not return. A customer-data product matches identities. An AI layer searches across all of them. Each can provide real value, but none should be mistaken for proof that the underlying path is now simple.

The AI add-on is still an add-on

A copilot may make the suite easier to search or operate. It can summarize a dependable record, retrieve approved knowledge, classify work, draft communication, and assist a stable process. Those are useful capabilities.

It also introduces a model, grounding sources, connectors, indexes or live queries, instructions, agent identities, permissions, tool calls, evaluation, logs, monitoring, credits, and a retirement decision. If the sources disagree, AI can create a fluent synthesis of the disagreement rather than resolve it. If access is overly broad, the assistant can inherit that oversharing. If it can write, an incorrect answer can become an incorrect operational event.

The useful question is not “Does our current platform include AI?” It is “Which narrow decision becomes safer, faster, or more useful after the full control layer is included?” If the business cannot identify the authoritative sources and approved actions, it is buying an interface before defining the system that interface is meant to operate.

Measure lock-in as exit cost, not vendor motive

The European Union’s Data Act directly recognizes switching barriers in data-processing services. Its current guidance says providers of Platform as a Service and Software as a Service must make open interfaces available and, at minimum, support export in a commonly used, machine-readable format. That policy would not be necessary if a subscription could always be replaced by downloading a simple file.

The UK Competition and Markets Authority reached a related—but narrower—finding in its 2025 cloud infrastructure investigation. It found technical and commercial switching barriers, including different interfaces, limited skill transfer, and data-egress costs. The report concerns IaaS and PaaS, not every CRM or small-business SaaS product, so it should not be generalized as a verdict on all software. It does show that structural lock-in can be measured without proving a secret intention to create it.

For a business application, the exit cost includes more than exported rows:

• Relationships between records and the identifiers that preserve them
• Field definitions, custom objects, validation rules, and calculation logic
• Files, notes, communication history, consent, and audit events
• Automations, approvals, routing, integrations, and failure handling
• Roles, permissions, service identities, and security assumptions
• Reports, semantic definitions, dashboards, and scheduled distribution
• Employee knowledge, training, documentation, and temporary parallel operation

A machine-readable export is essential, but portability is not complete until the business can reproduce the required function and evidence somewhere else.

Run the add-on test before the purchase

1. Name the business problem without using the product’s feature name.
2. Show the current record path and the exact point where it fails.
3. Confirm whether existing configuration can solve the problem first.
4. Define the new data, identities, permissions, and handoffs the add-on creates.
5. List every required tier, connector, credit, API, and support dependency.
6. Define success in a business measure, not adoption or feature usage alone.
7. Export a representative record, its relationships, files, and history before signing.
8. Document how the workflow would continue if the add-on were removed.
9. Assign someone to review usage, value, access, and retirement on a named date.

This is not an argument against buying software. It is a way to make the dependency visible while the business still has negotiating power and architectural choice.

When an add-on earns its place

An additional product or module is easier to defend when:

• It performs a distinct function the current stack cannot reasonably support.
• The authoritative data and status transitions are already defined.
• Its identity, permission, and failure behavior are testable.
• The business outcome is measurable after the full operating cost.
• The export and retirement path are understood before implementation.
• The new capability removes more complexity than it creates.

The objective is not the fewest possible tools. It is a stack in which each tool earns its role and no critical process remains understandable only from inside one vendor’s configuration.

Use tool stack implementation when the immediate decision concerns software, configuration, connections, migration, or retirement. Use business systems consulting when the problem also involves definitions, recurring work, reporting, and how the company makes internal decisions.

The evidence boundary

• Modular architecture does not prove a product was designed to create fragmentation.
• Paid add-ons do not prove malicious intent; they can fund genuinely useful, optional capability.
• A suite can reduce integration work, but a shared brand does not guarantee shared operational truth.
• Open APIs and exports reduce switching friction; they do not recreate workflow meaning automatically.
• The CMA findings cited here concern cloud infrastructure, not every business-software market.
• The EU Data Act establishes switching duties, not proof that every provider previously blocked every exit.

“Trap” is used here to describe the observable condition in which cumulative dependencies make exit or change materially harder than entry. The responsible test is the dependency surface and exit cost—not an assumption about intent.