Integration Marketplace — Why We *Didn't* Build One at First, and Why We Did Now

In CollabOps's first nine months we made one decision — no integration marketplace. When we cut from 8 to 4 launch features, the marketplace was the first thing cut. Reason: customers weren't asking for it.

At month twelve, we reversed. Marketplace ships in three quarters. What changed.

Four reasons we didn't build it at first

1. Users < 100 — marketplace value scales as N × M (users × integrations). Small N → marketplace value ≈ 0
2. We could build the first 8 integrations ourselves — Slack, GitHub, GitLab, JIRA, PagerDuty, Datadog, Sentry, OpenTelemetry. Covers 80% of use cases
3. Ambiguous responsibility for 3rd-party integrations — when an integration breaks, is it our problem? the integration author's? The answer must be clear
4. API stability was poor — our API changed every quarter. Marketplace integrations would need updates every API change = operational burden

Four reasons we reversed at month twelve

1. Users ~150 — N crossed the threshold
2. After our 8, integrations 9–30 cost us more than the value — niche vendor integrations (e.g., a Korean-specific monitoring tool) consume our time disproportionately
3. Customers want to build integrations themselves — customer SI teams and internal teams want to integrate their internal tools
4. Our API is relatively stable now — quarterly changes → annual. The premise of a marketplace is finally satisfied

Three subsequent decisions

After deciding to reverse, the fine-grained decisions:

Decision 1 — what goes in the marketplace

Choice: integrations only (CollabOps ↔ other tools). Other categories (templates, agent skills, themes) go elsewhere. Without this clarity, the marketplace evolves into the everything bin.

Decision 2 — who can publish

Choice: three tiers:

• Verified — we vet, hosted on our domain
• Partner — partner companies build, separate hosting OK
• Community — anyone publishes, unverified label

Each tier has different commitments. Verified gets a 24-hour response SLA. Community is as-is.

Decision 3 — revenue split

Choice: free for the first 12 months. Decide on paid integrations later. Setting a revenue model up front risks killing ecosystem formation itself.

The real marketplace KPI

The KPI isn't count of integrations. Assuming more integrations → KPI rises automatically is a common error.

Real KPIs:

• Active users per integration — 90 of 100 integrations with zero users is meaningless
• Integration → contract conversion — % of contracts where this integration was the deciding factor
• SLA adherence for verified integrations — response time

So when should you actually build a marketplace?

Build an integration marketplace only after all four conditions resolve — user count crosses its threshold, the integrations you can build yourself are exhausted, the 3rd-party responsibility model is clear, and the API is stable. For us that was ~150 users and 8 self-built integrations in. If you're a product lead deciding whether to build one, check those four conditions first. Building too early produces an empty marketplace, which is negative signal.