App Flow: First Pilot

From Mosaic to a Real Pilot

In my Mosaic writing, I explored the idea of moving from static apps to adaptive flows. This post is a practical first pilot of that idea.

If you have not read it yet, this pilot connects directly to Mosaic: From App Stores to App Flows.

I am experimenting with a simple principle: build disposable micro-apps that each do one thing well, and let users chain them when they need a longer workflow.

Why App Flow Instead of One Big App?

A fair question is: why not one big tournament app with optional steps?

Even if those steps are optional, the controls still exist in the interface. More operations usually means more controls. More controls means more mental load. More mental load means a higher learning curve.

For example, a teacher who just wants to randomly group students for an assignment should not need to parse bracket and qualification concepts. Optional complexity is still complexity when it is visible.

The pilot follows a few constraints that I care about:

• Each app is useful by itself: one input, one output.
• Users can start anywhere and stop anywhere.
• When needed, one tap chains output into the next app.
• Data handoff is URL-based, not server-side orchestration.

This keeps each tool lightweight and reduces feature bloat. A user who only needs one step should not pay a cognitive tax for the whole tournament pipeline.

In short, app flow is not anti-feature. It is anti-friction for users who only need one result.

Squad Shuffer Alone Is Already Useful

Squad Shuffer is a tiny app that creates groups or pairs from a list of names.

Even without chaining, it has practical value for collaboration. Users can copy an editable link, share it with another person, or open it in another tab to adjust results.

That is helpful when a group wants to rename teams or swap members to better match skill levels before playing.

Path A: Group Stage Then Bracket

When we chain from Squad Shuffer into Group Qualifier, the next app opens pre-filled.

In this pilot case, we have 8 teams, split into 2 groups, and qualify 2 teams from each group. That creates a round-robin stage where each group of 4 plays 6 matches, so the two groups produce 12 games total.

This is valuable because every team gets more playtime before elimination pressure begins.

After 4 teams qualify, results can chain forward into Tournament Bracket.

Path B: Direct to Bracket (Skip Group Stage)

The beauty of app flow is that the long path is optional.

Users can chain from Squad Shuffer straight to bracket generation if they want a faster tournament setup.

Benefits of Chaining as App Flow

This first pilot confirms the behavior I wanted:

• Flexible depth: users choose lightweight or full workflow per context.
• Faster starts: no mandatory wizard for users who only need one outcome.
• Higher replayability: each app can be reused in different chains.
• Clear mental model: one app, one promise, optional next step.
• Privacy-friendly handoff: flow state travels in the URL, not a central server session.

It is still early, but this feels like a practical bridge between the Mosaic vision and product behavior users can already touch.

Potential Drawbacks (and How I am Handling Them)

App flow also has tradeoffs, and I want to be explicit about them.

• Discovery cost: users may not know what can chain next.
• Mitigation: after results are generated, show clear candidate apps that this output can flow into.
• Context switching: moving between apps can feel fragmented if handoff is weak.
• Mitigation: open the next app pre-filled and preserve naming and structure from the previous result.
• Chain quality risk: bad defaults in one app can propagate downstream.
• Mitigation: keep each app editable after handoff so users can correct and re-chain quickly.

Future of App Flow

I will keep experimenting with what else can be chained and how far this model can go.

Beyond tournaments, the next questions I want to test are:

• Can app flow work for classroom and workshop operations, not just games?
• Can we build short productivity chains where each step stays disposable?
• Can chain suggestions become smarter based on result shape and user intent?
• Can flow templates emerge naturally from how people actually chain apps?

The goal is still the same: one small app should be complete on its own, but also become a clean building block for bigger outcomes when users need more.