eJoin — A PWA that adapts to real-world flow

eJoin is a progressive web app that lets people join without standing in line.

No download.

No setup.

Just scan and join.

Most systems try to control queues.

eJoin does something simpler:

It adapts to what is already happening.

People move.

Staff step in and out.

Capacity changes.

The system follows — not the other way around.

At the core is a single concept:

A line that doesn't reset.

The same line can behave differently depending on the situation:

• Staff present → flow is guided

• No staff → guests move themselves

• Capacity changes → multiple people can be served at once

No switching systems.

No clearing queues.

Just one structure adapting in real time.

Many real-world situations aren't single-file:

• 3 showers

• 4 gym stations

• 6 bikes available

Instead of one-by-one flow, eJoin reflects shared capacity directly.

For example:

"2 in use · 1 free"

Multiple guests can move at once — naturally.

People don't queue alone.

They arrive:

• in groups

• at different times

• with changing plans

eJoin treats groups as the default and allows:

• joining together

• joining later

• stepping in when ready

Without breaking the flow.

eJoin is built as a progressive web app because:

• Guests won't download an app for a single visit

• Access needs to be instant (QR → join)

• The same system should work across many contexts

For repeat use, it can be added to the home screen — but it's never required.

This is a working model being tested in real settings:

• Persistent queues (that last beyond a single session)

• Intent without commitment (joining ahead of time, without reservation)

• Shared capacity across multiple units

• Seamless shifts between staff-led and self-led flow

The goal is not optimization.

It's alignment with reality.

eJoin is currently used in a mix of environments:

• Restaurants (dine-in and takeaway)

• Coffee bikes and pop-ups

• Bike rentals

• Gyms and shared equipment

• Festivals (including showers and food stands)

• Workshops and shared tools

• Residential laundry rooms

• Events with fixed spots (e.g. school plays)

Different contexts.

Same underlying model.

• Calm over urgency

• Fairness, quietly

• No exact timing promises

• No rigid enforcement

The system supports decisions — it doesn't make them.

eJoin is in beta.

The system is live and used in real scenarios, but still evolving.

We're paying attention to:

• where behavior diverges from expectations

• what feels natural vs forced

• how little structure is actually needed

If you work with:

• PWAs

• real-world UX

• service design

We'd value your perspective.

Does this model make sense outside of controlled environments?