wabi

Overview

Wabi is a product for collecting media across formats — films, music, books, games, articles, performances — and organizing them into collections that show how works relate to each other.

I started it because most platforms treat media as isolated titles in a feed or a catalog. I wanted a system where a song could sit next to the film it inspired, or a book next to the older work it adapts.

The product is still evolving. This is a write-up of the system, not a launch story.

The product problem

Most media platforms are organized around individual titles, ratings, or algorithmic recommendation. Discovery happens through similarity scores and trending feeds.

Wabi explores a different model: human-curated collections, plus explicit relationships between works. A collection might connect a song to the track it samples, a film to the book it adapts, or newer media to the works that shaped it.

The design problem is making that model flexible enough for many formats without making the interface feel like a database.

Defining the content model

A song, a novel, and a game don't share the same metadata, but they need to live in the same collection. The system represents them as one kind of record: a media entry.

I moved from a flat list of types (music, book, film) to a two-level taxonomy. Form is the experience. Format is the artifact.

Shared fields stay small: title, creator, year, notes, source link, cover image. Format-specific detail can grow later without splitting the object model.

Media entries are first-class. A work can appear in multiple collections and take part in relationships without being duplicated. Relationships are their own records — from work, to work, a type, and an optional note — so the interface can say why two pieces belong together.

Designing collections

Collections are the main surface. Mixed media has to coexist in one list: a film still, an album cover, and a book jacket in the same scroll.

The questions that shaped the UI:

• How media is added — search an existing entry, create a new one, or paste a URL and extract metadata
• How different formats share a row without one dominating
• How collection descriptions and per-item notes explain why things belong together
• When to show a list (context) versus a grid (imagery)

Designing connections

Putting items next to each other is only adjacency. Relationships are meant to carry meaning.

That idea affected both the interface and the data model. Connections are authored records with optional notes, not inferred tags. The current UI leans on a simpler “Reminds me of…” flow — pick related works, optionally explain why — while the schema still supports more specific types.

The open design question is how much of that vocabulary should be visible, and how much should stay in the model until the product knows which distinctions people actually use.

Building the product

A few implementation choices directly shaped the experience:

• Media entries as a reusable layer. Collections are ordered joins with per-item notes, not copies of the work. The same film can live in several collections and several connections.
• One Postgres schema via Prisma. Collections, media, relationships, and public/private visibility live together, which made it possible to change the taxonomy without rewriting the product.
• Dual-write during the taxonomy change. Older mediaType values and the newer form/format columns were written together so existing data kept working.
• URL metadata extraction. Pasting a link fills title, creator, image, and a suggested form/format — so adding a work stays close to a few seconds.
• Next.js App Router, Better Auth, Supabase storage. Server-rendered routes for media, collections, and profiles; accounts and covers without a custom backend.
• Shared UI. Tailwind and shadcn/ui keep library, collection, and media pages in one component language.

The schema is still named around “playlists” in places. That leftover is part of the story: the product started closer to mixed-media playlists and is moving toward collections and relationships.

Iteration

Working in the actual product changed the questions. Early on, Wabi could have been a personal shelf, a discovery network, or a relationship graph. Building it made those options concrete:

• Is the core value personal curation, or discovery?
• Are relationships the differentiator, or are collections enough?
• How much structure should a collection impose?
• Where do profiles, likes, and follows belong if the point is the work, not the social graph?

The first version also tried to do too much. Features got stripped so adding a work and explaining a collection stayed fast. Direction is still being refined — that's expected, not a failure of the original idea.

Current state

Wabi is a working product, not a public launch. You can create collections, add mixed media, attach notes, connect works, and keep collections private or public.

What I'm prioritizing next:

1. Make relationships clearer in the UI — the model is richer than what the interface currently exposes.
2. Search and discovery that use collections and connections, not just recency.
3. Profiles and collaboration only where they support curation.

Richer metadata, recommendations, and deeper mapping can wait until the core loop is obvious.

Reflection

The useful work was designing a system, not a set of screens. Once media, collections, and relationships were separate objects, the interface had somewhere to go.

Building it also forced scope. A flexible model only matters if adding a book to a collection still takes a few seconds. Implementation kept showing where the concept was too ambitious — or not ambitious enough — especially around whether “this reminds me of” is a full relationship system or just a note.

The open question is still the right one: how much structure to show, and how much to keep in the model until the product knows what it is.