The Layer Most Super Apps Forget: Building an Enterprise Mini-App Store

You built the runtime. Services accumulate. Then growth stalls — because building a mini-app and making it discoverable are different problems. Here's the distribution layer.

There's a super app failure mode that only appears after success: you embed a runtime, services accumulate to 30-50 mini-apps, and every build metric looks great — but growth flatlines. The app got dense, not dynamic. Users can't find services, new ones launch invisible, and every partner onboarding needs your platform team. You solved building. You never built distribution. Let's fix that.

The problem: a grid of icons doesn't scale

5 mini-apps:   one screen, everyone finds everything. Discovery = trivial.
20 mini-apps:  users start missing things.
50 mini-apps:  the grid is a wall. Users see what they already use;
               new services are invisible; partner onboarding is manual.

The grid that works perfectly at 5 is silently load-bearing, and it fails without an error message. You need three things it can't provide: discovery, self-service publishing, and governance.

Part 1: discovery as a designed experience

Not a listing — a system that surfaces the right service at the right moment:

// Discovery isn't "list all mini-apps." It's contextual + personalized.
async function getDiscoverySurface(user, context) {
  return {
    // Contextual: services relevant to what the user is doing NOW
    contextual: await surface.forContext(context),
    // e.g. context = "viewing_order" → surface returns/refund mini-apps
    //      context = "checkout"      → loyalty/points mini-app

    // Personalized: based on role, history, segment
    recommended: await surface.forUser(user, {
      role: user.role,
      recentlyUsed: user.miniAppHistory,
      segment: user.segment
    }),

    // Searchable: because at 50 services, browse isn't enough
    searchIndex: "miniapps",   // full-text + semantic over titles, tags, descriptions

    // Categorized: navigable structure
    categories: await catalog.categories({ visibleTo: user })
  };
}

The key line is visibleTo: user — discovery and governance are the same system. What a user can find is exactly what they're permitted to access.

Part 2: self-service publishing (the growth-decoupler)

This is the single change that separates a platform from a bottleneck. If every publish needs your team, ecosystem growth is capped at your team's capacity:

# The publishing pipeline — partners/teams drive it, platform governs it
publish_pipeline:
  submit:
    actor: partner_or_internal_team   # NOT the platform team
    provides: [package, manifest, requested_capabilities, category, visibility]

  automated_checks:
    - package_integrity
    - static_security_scan
    - capability_request_validation    # are they asking for more than allowed?
    - performance_budget_check

  review:
    mode: approval_workflow            # human gate, but a QUEUE not a bespoke project
    reviewers: [platform_admin, security]
    sla: "3 business days"

  publish:
    rollout: gray                      # 5% → widen, never straight to 100%
    visibility: per_manifest           # who sees it (governed)

  post_publish:
    monitoring: automatic
    rollback: one_click

The distinction that matters: the platform team designs and governs this pipeline once. It does not operate it per-publication. A partner submits, automated checks run, a reviewer approves from a queue, it goes live. Ecosystem growth decouples from core-team headcount.

Part 3: governance — the other face of discovery

An enterprise store is curated and permissioned, not an open bazaar:

governance:
  visibility_rules:
    - miniapp: hr_portal
      visible_to: { employees: true, partners: false, public: false }
    - miniapp: partner_insurance
      visible_to: { regions: [SG, MY], segments: [premium] }
    - miniapp: summer_campaign
      visible_to: { rollout_cohort: "5pct_test" }

  approval:
    new_miniapp: required
    version_update: required_if_new_capabilities
    partner_publish: required

  lifecycle:
    suspend: instant           # pull a misbehaving service immediately
    rollback: per_miniapp       # revert one, touch nothing else
    retire: clean               # no dead entries left in the catalog

Part 4: measure what circulates, not what exists

Counting services measures your work. Measuring circulation tells you if it's an ecosystem:

// The questions that actually matter post-launch:
analytics.query({
  perMiniApp: [
    "unique_users",           // is anyone finding it?
    "discovery_source",       // search? contextual? category? (what works)
    "retention_30d",          // do they come back?
    "conversion_funnel"       // does it do its job?
  ],
  ecosystem: [
    "services_with_zero_usage",   // how many launched into the void?
    "time_from_submit_to_live",   // is publishing actually self-service?
    "new_services_per_month"      // is the flywheel accelerating?
  ]
});

services_with_zero_usage is the metric that exposes a broken discovery layer. If it's climbing, you're building into the void.

How it compounds: the flywheel runs through this layer

more services → findable (discovery) → app more useful →
  more users → more attractive to build → partners publish (self-service) →
  more services → ...

Break discovery: "more services → more useful" fails. Loop stalls.
Break publishing: "more users → more services" fails. Loop stalls.

The distribution layer isn't one component — it's the medium the flywheel's causation flows through. This is why FinClip's management platform is built as an enterprise mini-app store: self-service publishing with approval workflow, RBAC-governed visibility, phased rollout by region/device/segment, suspend/rollback, and 20+ analytics metrics showing what circulates vs. what sits idle. The runtime lets you build the ecosystem; the store is what lets it move.

The test

1. At 50 mini-apps, can a user find the one they need — search, contextual, personalized — or just scroll a grid?
2. Can a partner go from submit to live without your platform team operating the process?
3. Is visibility governed per-service (role, region, segment), or all-or-nothing?
4. Do you measure services_with_zero_usage — do you know how many launched into the void?

If publishing needs your team and discovery is a grid, your ecosystem is capped at your team's capacity and your users' patience. Which did you build — a runtime, or a runtime plus a way for things to circulate through it? 👇

---

More on super app distribution, ecosystem design, and platform infrastructure → https://super-apps.ai/