Musephoria was an attempt to build the feedback layer the internet never got around to building for musicians. Not a social network, not a streaming platform — a structured exchange where you review someone else’s work in order to earn the right to have yours reviewed.
I worked on it, on and off, from late 2023 through mid-2025. It is not running today. What follows is what the design got right, what the engineering got wrong, and the thing I actually learned, which was not about music.
The problem
Every platform that hosts creative work eventually converges on the same failure. Feedback is expensive to give and cheap to receive, so people stop giving it. What fills the vacuum is applause — the fire emoji, the ”🔥 tune,” the reciprocal follow. Applause is socially pleasant and informationally worthless. An artist who wants to know whether the second chorus lands cannot find out.
The obvious fix is a karma system: give feedback, earn feedback. But naive reciprocity produces exactly the pathology you would predict. If a review is the price of admission, people pay the lowest price that clears. You get “sounds great man!” at scale, which is worse than silence, because now the system is reporting that feedback happened.
So the real problem is not building an exchange. It is making the cheap move unavailable.
The mechanism
Most of the design work went here, and it is the part I still think was right.
Gated playback. You cannot hear the full track until you answer structured questions about it. The questions unlock progressively, tied to timestamps in the audio. You cannot skim to the end and generalize, because the interface does not let you arrive at the end without passing through the middle.
Timed review forms. Sections trigger at defined points in playback. The constraint is not “spend five minutes on this” — it is that the form’s shape is welded to the shape of the song. Feedback about the bridge appears when you are listening to the bridge.
LLM validation as a scoring layer, not a gate. A small model scores submitted reviews for specificity, tone, and helpfulness. Critically, it does not block anything. It adjusts your reputation and your reward rate. The distinction matters: a gate creates an adversarial relationship with a classifier, and people optimize against classifiers. A score creates a gradient, and people drift up it.
Reputation-weighted rating. Recipients rate the reviews they receive, but those ratings are themselves weighted by the rater’s own standing. A drive-by account’s opinion about review quality counts for very little. This is the piece that keeps the system from being captured by whoever shows up most.
Arbitration for the hard cases. When the model classifies a dispute as borderline, it routes to three karma-qualified users who must reach unanimity within 24 hours, with a second round and then a human escalation if they cannot. Arbiters can report each other for bad faith; false reports carry a penalty.
The default the whole system leans on: protect sharp, honest criticism over performative politeness. Harsh-but-fair had to survive, or the platform would converge on applause by a slower route.
The architecture, four times over
Here is where the project actually went wrong, and it is worth being precise about it.
Musephoria was rebuilt from the foundation four times in roughly two years:
- PlanetScale + Drizzle, MySQL-flavoured, early 2024
- Firebase, chosen for realtime subscriptions and cloud messaging, mid 2024
- Supabase, for Postgres and row-level security
- Self-hosted Postgres + Zero + Solid.js + Hono + Bun on SST, 2025
The final design was the most defensible on paper. Zero gives local-first querying with real-time sync, optimistic updates, and offline support, which removes an enormous amount of client cache plumbing. Solid’s fine-grained reactivity avoids virtual-DOM overhead, which matters when you are drawing waveforms and driving tightly-timed audio playback. Hono with zValidator and the hc() client gives end-to-end type inference across the client-server boundary with no codegen and no React dependency. Postgres with pgvector handles embedding-based reviewer and genre matching in the same database as everything else. Cloudflare R2 stores audio with no egress fees.
I can still justify every one of those choices individually. That is the trap.
Each migration was triggered by a real limitation. Each replacement genuinely addressed it. And the cumulative effect was that a system with a fully specified schema — users, sessions, songs, reviews, karma, arbitration cases, strikes, all of it — never got far enough past scaffolding to put the mechanism in front of a single real musician.
What it actually taught me
The design document runs to several thousand words and specifies a functioning trust economy in detail. The build log, over the same period, is mostly better auth, basic scaffolding, user onboarding.
That ratio is the finding.
The mechanism design was the interesting problem, so it is where the effort went — and mechanism design has the seductive property that you can keep doing it indefinitely without ever contacting reality. Every hour spent refining arbitration tie-breaking rules felt like progress. None of it was falsifiable. Meanwhile the only question that mattered — will two strangers actually give each other useful feedback under these constraints — needed maybe a tenth of that system to test, and could have been answered in a month with a form, a queue, and twenty people from a Discord server.
The stack churn was the same disease wearing engineering clothes. Migrating to Zero was defensible, well-reasoned, and a way to spend three weeks doing something legible instead of something risky.
There was one exception to the pattern, and it is telling. Over 4.5 hours at an OpenAI hackathon, a collaborator and I shipped two working pieces: a real-time inline writing assistant that underlines weak spots in a review as you type and explains them on hover, and a quorum validator that runs three agents — terms-of-service, actionability, and tone — in parallel, then hands their verdicts to a coordinator agent that allows, flags, or denies.
Both of those had been sitting in the design document for months. Under a hard deadline, with no room to reconsider the database, they took an afternoon.
Status
Archived. The schema, the mechanism design, and the stack rationale are intact, and the ideas in the review-integrity system are the part I would carry into anything similar. If I return to it, it will start from the constraint that nothing gets built until the reciprocity loop has been tested on real people with no infrastructure behind it at all.