We shipped 3 features in one flow today: Shop + Crowdfunding + Live. Here's the integration design.

A short build-in-public note from today.

We finished shipping the web implementation of Matsuri Platform. Three features now operate as a single integrated flow on the web:

• Shop (marketplace)
• Crowdfunding
• Live Streaming that runs across both — and across in-person events

This post is the design retro, not the press release.

The integration target

Watching a stream → wanting the product → buying it → backing the maker's next project. That arc is one human behavior. In today's tooling it's split across three apps with three identities, three payment flows, and three reputation systems.

We collapsed that.

• A shop seller can broadcast live while selling their products.
• A crowdfunding creator can show progress live while gathering support.
• An event organizer can run on-site logistics and live operations through the same flow.
• Audiences move freely between watching, supporting, buying, and broadcasting.

1. Data model: Liveable as a first-class union

We didn't model 'a stream' as the unit. We modeled what flowed through a stream.

type Liveable =
  | { kind: 'shop_item'; itemId: string; price: Money }
  | { kind: 'crowdfund_project'; projectId: string; goal: Money; raised: Money }
  | { kind: 'event'; eventId: string; venue?: Venue };

type LiveSession = {
  hostUserId: string;
  startedAt: DateTime;
  status: 'preparing' | 'live' | 'ended';
  attachedLiveables: Liveable[];   // multiple sellable things per session
  metrics: {
    concurrentViewers: number;
    totalGmv: Money;               // money that moved during the stream
    pledgesPlaced: number;
    itemsSold: number;
  };
};

A stream is just a window through which Liveables are exposed.

2. Primary metric: totalGmv, not concurrent viewers

Most live platforms make concurrent-viewer count the lead indicator. We don't.

function primaryMetric(session: LiveSession): MetricCard {
  return {
    label: 'Live GMV',
    value: session.metrics.totalGmv,
    secondary: [
      { label: 'Items sold', value: session.metrics.itemsSold },
      { label: 'Pledges',    value: session.metrics.pledgesPlaced },
      { label: 'Viewers',    value: session.metrics.concurrentViewers },
    ],
  };
}

Leading on viewers optimizes for hype. Leading on GMV optimizes for trust. We chose the second on purpose.

3. Checkout inside the stream: 3 taps, no exit

Live commerce dies on payment friction. We force the path to be:

long-press item card → confirm modal → 1-tap purchase

Three taps. Stream never exits. Logged-in users never re-authenticate during a session.

For this to work, Shop / Crowdfunding / Event all had to share one Wallet context. That is what 'integration' actually meant in implementation: not unified UI, unified state.

4. Native app: web is the source of truth

Next phase is iOS / Android. Policy:

• The web flow is the source of truth. Native ports the web; we don't fork behavior.
• Web and native share the same API contracts.
• Native only diverges where Apple / Google review explicitly requires it.

5. Why we didn't 'launch' today

'Web is done' means touchable, not finished. A loud launch right now would burn trust against an experience we haven't yet polished with real users.

May is for locking the foundation alongside our first event organizers and creators. June is when real operations begin and the platform starts moving for real.

In this phase, implementation logs > press releases. That's the right form of announcement for what's actually happening.

What I'd love to hear

If you've shipped commerce-adjacent live experiences: what was the seam that broke first under real load — identity, payments, moderation, or something else?

If you're still on the design side: which of these three features do you think most needs to be in the same screen as the others?

---

Ko Takahashi (高橋高) — CEO of Jon & Coo Inc., Lead Architect of Matsuri Platform, Editor in Chief of The J-Times. Tokyo. ko-takahashi.jp · matsuri.group · j-times.org.