build-platform-strategy

name	Build Platform Strategy
description	Create a platform strategy that enables third-party developers to build on top of your product. When evaluating whether to stay vertical or open an ecosystem. Trigger on: developer experience, ecosystem, API strategy, third-party integration, marketplace, platform launch, governance.
dependencies	[]
connectors	[{"name":"Linear","reason":"Tracks platform development roadmap, API features, developer feedback"},{"name":"Slack","reason":"Developer community channel for feedback, support, and ecosystem coordination"},{"name":"Notion","reason":"Stores developer documentation, API specs, governance framework"},{"name":"Google Drive","reason":"Hosts integration guides, technical specs, partner agreements"},{"name":"Intercom","reason":"Manages developer support tickets and feature requests from third parties"}]
author	Harmony
version	1.0.0
icon	sparkles
cover
screenshots	[]
category	Product

Purpose

A platform transforms your product from a closed system into an ecosystem where developers build on top of it, expanding capability without increasing your team. Platforms create network effects: more developers → more apps → more users → more developers. The shift from product to platform is not about adding APIs and calling it done. It requires rethinking everything: governance (what can third parties do?), developer experience (how fast can someone build?), economics (how do you capture value?), and go-to-market (who are your developer champions?). This skill guides you through deciding whether a platform is right for your company, building it in phases, and measuring ecosystem health.

When to Use This

• You've achieved strong product-market fit but growth is plateauing despite adding features
• Customers repeatedly ask for integrations or custom extensions you can't build alone
• You're seeing users build workarounds or middleware; opportunity cost of building is clear
• Your roadmap is constrained by trying to serve every vertical use case
• You want to compete with larger platforms without building everything yourself
• You're losing deals to competitors with richer ecosystems
• Your product is mature enough to be stable; developer-facing features won't destabilize core
• You have the engineering resources to support a public API and developer community
• You're comfortable trading some control for faster innovation at the edges

Instructions

1. Evaluate Platform Timing and Market Fit

   • Assess your product maturity: is core product stable enough for external developers? (target: <1% daily API failures, documented patterns)
   • Map customer requests: are 20%+ of inbound asks about integrations, plugins, or custom extensions?
   • Research adjacent pain points: which use cases are outside your roadmap but highly requested?
   • Analyze competitor ecosystems: how many apps does your closest competitor have? How active is their marketplace?
   • Calculate internal capacity: how many engineers would it take to build the top 10 customer requests in-house? (if >3 FTE, platform economics favor opening)
   • Talk to 20 customers about a hypothetical platform: would they build on it? What integrations matter most?
   • Decision framework: if you can honestly say "we don't have enough engineers to serve all use cases," a platform is likely right

2. Define Platform Boundaries and Governance

   • Decide what developers CAN build: Can they access user data? Modify core workflows? Create revenue-sharing deals?
   • Create a tier system: basic integrations (webhooks, read-only APIs) vs. advanced (full data access, custom UI in your app)