At what point do you pivot from building native features to building deep integrations?
by•
Early on we built our own internal notifications, document storage and task lists. Post-monetization, churned feedback taught us a harsh lesson: users don't want another siloed app they want our core utility inside Slack, Notionor Chrome.
The hardest decision is stopping work on your own native capabilities to spend cycles building integrations for other platforms.
How do you determine when a workflow issue requires an ecosystem integration rather than an internal UI fix?
9 views
Replies
For a consumer app the ecosystem is the phone itself, and the test I use is where the action starts, not where it ends. For my song app the honest answer was "not inside the app": a birthday already sits in the phone's calendar, so the app reads the calendar instead of asking people to type dates in. And on iOS a song can be asked for from Siri, Shortcuts or Spotlight, through App Intents. None of that replaced a native screen, it gave the native screens more doors. So my rule would be: if the trigger for your core action lives in Slack or Chrome, integrate there; if the friction is inside your own flow, that one is still a UI fix.