Queue Cloud Functions

Purpose

Crew Queue was the vision: a matchmaking platform for music industry crews. Every crew needs roles — the Artist (performer), the Kingpin (producer), the QA (brand manager), the Jack of All Trades (merchant, roadie, the glue), and the 10 (the dime, the influencer, the face). The hypothesis: by clustering people with tons of overlap across taste, location, ambition, and complementary skills, you could assemble crews that actually work. Queue Cloud Functions was supposed to be the matching engine. It never got there.

Stack

What I Learned

• Matchmaking is a constraint satisfaction problem — you are not just finding similar people, you are finding complementary people whose overlap is in the right dimensions (taste, location, goals) while their differences are in the right dimensions (skills, roles, networks). Similar taste + different skills = a functional crew. Similar taste + similar skills = competition.
• The queue architecture for matchmaking typically works as a pipeline: users enter the queue with their profile data, cloud functions score every viable pair/group against a compatibility model, top matches are surfaced, and users accept or reject. The scoring function is where all the product decisions live — how much weight on musical taste vs. geographic proximity vs. role complementarity.
• Cloud Functions are event-driven by nature, which maps well to queue processing: a new user enters the queue (Firestore write event), a function triggers, scores them against existing queue members, writes match candidates to a results collection, and another function notifies matched users. The pipeline is reactive, not polled.
• The crew roles — Artist, Kingpin, QA, Jack of All Trades, 10 — are an archetype system. Every successful music operation has these functions filled, whether explicitly or accidentally. The insight is that matchmaking is not just about connecting individuals — it is about assembling a system where every role is covered and the personalities mesh.
• This project failed because the matching algorithm was the easy part and the hard part was user acquisition. A matchmaking platform with no users has no matches. The cold start problem in two-sided marketplaces is brutal: you need supply to attract demand and demand to attract supply. The cloud functions worked. The chicken-and-egg problem did not.

Key Insights

• The gap between vision and execution is not a technical gap — it is a prioritization gap. Crew Queue had a compelling vision, a reasonable architecture, and a working backend skeleton. What it did not have was a path to the first 100 users. Building the matching engine before solving distribution is the classic technical founder mistake: optimizing the machine before confirming anyone wants to stand in front of it.
• Matchmaking systems underpin more products than people realize: dating apps (Tinder, Hinge), freelancer platforms (Upwork, Fiverr), gaming lobbies (every multiplayer game), ride-sharing (Uber matching riders to drivers), and job boards (LinkedIn, Indeed). The core problem is identical: given a pool of candidates with attributes, find the best pairing under constraints. The scoring function and the UX change. The architecture does not.
• The crew archetype model — Artist, Kingpin, QA, Jack of All Trades, 10 — is actually a universal team composition framework. Every startup has these roles too: the visionary, the operator, the quality gatekeeper, the generalist who fills gaps, and the person who makes the thing look attractive to the outside world. The music industry just has better names for them.
• Unfinished projects with good architecture are not waste — they are inventory. The queue-based matching pipeline, the Firestore event-driven function chain, the role-based compatibility scoring — all of this is reusable. Crew Queue did not ship, but the patterns it explored have shown up in other projects since. Ideas that fail as products can succeed as education.