A quick build-in-public note before the launch.
This month we're shipping major updates to Matsuri Platform and The J-Times, our editorial media arm. The biggest change is live streaming integration. From June, we begin real operations.
The context: Matsuri is trying to be a community-run economic zone — a place where event organizers, local guides, cultural writers, filmmakers, and audiences earn and circulate inside a single platform, so participation translates into a livable income for as many people as possible.
Here are 5 design decisions we made along the way that I think are worth writing down before they become invisible.
1. We collapsed 4 apps into 1 platform
Early architecture had Matsuri as 4 separate apps:
- Festival discovery
- Editorial media (The J-Times)
- Payments & ticketing
- Live streaming
Independent UX, independent auth, independent billing. Faster to ship.
We collapsed them into one. The reason: a community economy needs role continuity for the same user.
User A on Tuesday: spectator
User A on Friday: event organizer
User A next week: tour guide
User A during a festival: live commerce supporter
If identity, reputation, and earnings are split across 4 apps, that continuity breaks. So we paid the integration cost up front.
2. We're avoiding 'follower count' as a primary metric
Most creator platforms make follower count the lead indicator. People who don't go viral disappear.
Our user model looks more like:
type UserRole =
| 'organizer'
| 'guide'
| 'writer'
| 'filmmaker'
| 'vendor'
| 'supporter';
type UserParticipation = {
roles: UserRole[]; // a user can hold multiple roles
contributions: Contribution[];
reputation: ReputationScore; // tracked per role, not aggregate
earnings: EarningStream[]; // crowdfunding + shop + live + tickets, unified
};
The primary indicator is what circulated through this user, in which role. Followers can show up later as a derived signal.
3. Live streaming is modeled as an economic event, not a broadcast
The stack underneath is comparable to YouTube Live or Twitch. The UX layer is not.
A Matsuri live event is wired so that, while the stream is running:
- Shop items can be purchased mid-stream
- Crowdfunding pledges to organizers can be placed
- Tour bookings with the on-camera guide can be made
- Viewers can publish a J-Times article off the back of the stream
The metric we care about is economic flow per stream, not concurrent viewer count.
4. We chose 'parallel cultures' over 'i18n localization'
The usual i18n model: take a Japanese UI, translate strings to English/Spanish/Portuguese.
We didn't do that. The content here is culture. A Japanese matsuri, a Brazilian festa, and a Taiwanese temple festival are not translations of each other — they're parallel.
× language=ja → language=en
○ context=jp-festival ‖ context=br-festival ‖ context=tw-festival
UI gets translated. Governance and content are local-authoritative.
5. We optimize for circulation depth, not DAU
The usual VC-backed playbook: maximize DAU/MAU first, monetize second.
We inverted it. Launch DAU targets are modest. The lead metric is how much money each participant earns and spends inside the ecosystem per month. Scale starts being interesting only after we can show the circulation is real.
Why I'm writing this now
Next month the platform is going to look like "an interesting festival app." That's the surface read. The architecture is aiming at a 3-year target: an economic zone that sustains the daily lives of hundreds of thousands of participants.
If any of this resonates with what you're building — especially if you're working on community-led economic infrastructure or DAO-adjacent platforms — I'd love to compare notes in the comments.
What's the design decision you are most likely to regret skipping when you launch?
Ko Takahashi (高橋高) — CEO of Jon & Coo Inc., Lead Architect of Matsuri Platform, Editor in Chief of The J-Times. Tokyo. More at ko-takahashi.jp. Matsuri at matsuri.group; J-Times at j-times.org.
Top comments (0)