Crew Queue v2

Purpose

Another attempt at bringing Crew Queue to life in Flutter. The concept — match musicians into functional crews based on role, taste overlap, and complementary skills — has persisted across multiple years and multiple tech stacks (Cloud Functions, Go, Flutter). It still occupies mind real estate. When an idea refuses to leave, the right response is to either ship it or architect it well enough that shipping becomes inevitable.

Stack

What I Learned

• A system like Crew Queue should be architected in three layers: the Profile Graph, the Matching Engine, and the Collaboration Layer. Each is independently complex. Together, they form the platform.
• Layer 1 — The Profile Graph: Every user has a profile with structured and unstructured data. Structured: role (Artist, Kingpin, QA, Jack, 10), location, experience level, genres, instruments/tools, availability. Unstructured: portfolio samples (tracks, mixes, designs), bio, vibe. The graph is the relationships between profiles — who has worked together, who has similar taste, who is in the same scene. Firestore handles the documents. A graph database (Neo4j, Dgraph) or Firestore subcollections with indexed fields handle the relationships.
• Layer 2 — The Matching Engine: This is the core algorithm. It runs server-side (Cloud Functions or a dedicated service). Input: a user seeking a crew or a crew seeking a member. Process: query the profile graph for candidates, score each candidate against a compatibility model (weighted factors: role fit, genre overlap, geographic proximity, availability alignment, past collaboration success), rank by score, return top N matches. The scoring weights are the product decisions — how much does genre overlap matter vs. location? These weights should be tunable and eventually learnable from match outcomes.
• Layer 3 — The Collaboration Layer: Matching is the introduction. Collaboration is the product. Once a crew is assembled, they need: a shared workspace (project board with tasks, deadlines, deliverables), real-time communication (chat, voice, video — or integrate with Discord/Slack), file sharing (stems, mixes, artwork, marketing assets), and a deliverable pipeline (the song goes from demo → mix → master → distribute). This layer is where the platform becomes sticky — matching gets users in the door, collaboration keeps them.
• The cold start problem (flagged in the original queue-cloud-functions entry) has a known solution for two-sided marketplaces: start with one side. Recruit artists first by offering a free portfolio page and a "looking for crew" badge. Build supply before you sell demand. Alternatively, start with a single scene (one city, one genre) where the density is high enough that matches happen naturally, then expand.
• The data model for compatibility scoring should be explicit: create a CompatibilityScore type with fields for each factor (genreOverlap: 0-1, roleComplement: 0-1, locationProximity: 0-1, availabilityMatch: 0-1, vibeAlignment: 0-1). The aggregate score is a weighted sum. Weights start as hand-tuned constants and evolve to ML-learned weights as match outcome data accumulates. Start simple. Get smart later.
• The crew itself is a document with members (array of user refs), roles (map of role → user), status (forming, active, completed, disbanded), deliverables (subcollection of song projects), and a health score (derived from activity, communication frequency, and deliverable completion rate). Crews that go silent should be surfaced for check-in. Crews that deliver should be celebrated and used as social proof for the platform.

Key Insights

• This idea has persisted across queue-cloud-functions (2019), Queue frontend (2021), and Crew Queue v2 (2023). Four years and three attempts. It still occupies mind real estate. The Intervolition pattern (three attempts before shipping in Swift) suggests that persistent ideas eventually find their form — but only if you keep working on them instead of just thinking about them.
• The architecture described above is not a fantasy spec — it is a buildable system. Each layer has existing tooling: Firestore for the profile graph, Cloud Functions for the matching engine, and Firebase Realtime Database or a real-time service like Liveblocks for the collaboration layer. The total infrastructure cost for a small-scale launch (100 users) is under $50/month. The barrier is not cost or technology. It is execution commitment.
• Crew Queue is one of those ideas that would benefit massively from AI in ways that did not exist during earlier attempts. An AI agent could: analyze uploaded music to auto-tag genre, mood, and production style (solving the profile data entry problem). Score vibe alignment by analyzing how users describe themselves vs. how their music sounds. Generate crew match explanations ("You and DJ Spudnik both produce lo-fi beats with jazz samples and are both looking for a vocalist in Denver"). The AI does not replace the matching engine — it enriches the inputs.
• If Crew Queue ever ships, it belongs under the Potatocore division — the media and content arm of Potatuhs. Music crews producing songs feeds the content pipeline. The songs become YouTube content. The YouTube content drives the brand. The brand drives merch. The merch funds the next season. Crew Queue is not a standalone app idea — it is a content acquisition engine for the ecosystem.