Building a Product Ecosystem Without Turning Everything Into One Super App

Reusing code is attractive. Reusing product decisions blindly is not. Two applications can share infrastructure while still needing completely different interfaces, onboarding and daily workflows.

Shared foundations are valuable

Authentication patterns, content services, analytics conventions, release tooling and common design primitives can reduce engineering cost across a product family. The mistake is assuming that shared foundations require a single giant user experience.

Different users have different jobs

A teacher preparing tomorrow’s lesson, a primary learner practising mathematics and an exam candidate running timed mock tests may all consume education content. Their goals, attention span and navigation patterns are different enough that one interface can easily become a compromise for everyone.

Separate products can make the platform clearer

Focused apps allow each home screen, progress model and notification strategy to reflect the audience. The underlying platform can still share services and operational tooling.

Architecture should make separation affordable

The goal is not to duplicate everything. Stable APIs, common data models and reusable libraries make it possible to build distinct products without rebuilding the entire stack.

The product boundary should follow the user’s mental model

I prefer to ask which tasks belong together for a specific user rather than which features can technically fit inside the same codebase. That usually leads to cleaner products and a healthier platform.