Working AtlasPlatform & product engineering

Shared Capability Studio

Compare how shared product capabilities trade local freedom for consistency and cross-team coordination.

TryCompare Shared flow with Separate flows. Select One path needs a local step; compare Shared core + adapters.

Watch forShared flow coordinates review across paths; separate copies can drift. Adapters keep local steps at their boundary.

Jump to the model

Separate teaching model

The linked story describes related work; the scenarios and results here are synthetic.

Interactive model

This is a synthetic platform-design exercise inspired by the general problem of building reusable capabilities for several product teams. It is not a diagram of Setu’s implementation, and the example paths carry no real adoption or outcome data.

Choose a platform shape

Capability structure

Change scenario

SYSTEM SHAPE

One capability, several paths

Common capabilityShared flow

EXAMPLE 01Path AUses the common flow
EXAMPLE 02Path BUses the common flow
EXAMPLE 03Path CUses the common flow

Three invented paths for comparison. They do not represent Setu products, teams, or adoption counts.

Organization model

Shared flow

Qualitative comparison; no adoption counts

TRADE-OFF

One shared change reaches every adopting path.

A common rule is easier to keep consistent, while a shared change needs coordinated validation across its adopters.

Review scope. All paths connected to the shared flow are in the review scope.

Design review promptHave the affected product teams reviewed the shared behavior together?

Preparing the interactive experiment…

Skill practicedDesign platform boundaries that several teams can use

Connection to my workAt Setu, shared Bridge/Admin capabilities support about seven teams; this exercise explores shared versus team-local boundaries.

Understand the result

Compare three invented ways to organize a capability across example product paths: one shared flow, a shared core with local adapters, or separate flow copies. Then change either a shared requirement or one path’s local need and inspect the review scope and trade-offs. It is a platform-design exercise, not a model of Setu products, teams, service internals, or outcomes.

Controls

Capability structure: Choose one shared flow, a shared core with adapters, or independently maintained flow copies.
Change scenario: Choose whether a shared requirement changes or one example path needs a local step.

What to watch for

A shared flow keeps common behavior together, but every adopting path belongs in a coordinated review when it changes.
Separate copies make local changes straightforward, but repeated rules can drift when the same requirement changes.
A shared core with adapters can separate common guarantees from local steps, while leaving adapter boundaries to review.

Why it happens

A platform boundary decides which behavior is common and which variation remains local. Sharing can reduce duplicated rules, but broadens coordination and validation. Local copies or adapters can preserve fit, but need clear ownership and checks so they do not silently diverge. The right boundary depends on the real products and their constraints; this qualitative exercise assigns no team counts, costs, or outcomes.

How this idea relates to the linked work

At Setu, shared Bridge and Admin capabilities support approximately seven product teams. One documented example is a centralized KYC transition flow that brought fragmented product journeys together. This separate, synthetic exercise helps me reason about where shared behavior and local variation should live; it does not reproduce that flow or describe Setu’s implementation, adoption, or outcomes.

See the broader engineering brief