The hard part wasn't building it. It was deciding what it wasn't.
Riffims. Launch coach for independent musicians. Product, design, engineering and deployment, solo, in production in under three months.
Five tools, zero process. None of them teaches.
An independent artist who wants to release music today needs a DAW to record, a distributor to upload, a design tool for the cover art, a spreadsheet to plan dates and a search engine to figure out what ISRC or splits mean. Five tools that don't talk to each other, and none that tells them where to start.
The problem isn't a lack of tools. Most independent artists already have access to everything they need and still don't know in what order to use it. They don't know the industry's processes or its vocabulary, and they don't have a team to ask. Distributors receive the track and stay silent about everything else. Tutorials answer one question at a time and assume you already know which one to ask.
I didn't research this from the outside. I'm an independent artist, and the most important people in my life are too. The chaos this project describes is the one I've been watching up close for years.
What's missing is an order. That's the premise of Riffims, and also the hypothesis this project still has to validate.
A coach, not a distributor
The first real decision was by subtraction. Riffims is not a distributor, not a DAW, not a social media manager. It doesn't receive the track and it doesn't publish it anywhere. It's a coach that guides the entire release and teaches the industry along the way.
That constraint did most of the work during the following three months. Every idea I had for the product was measured against it, and the ones that would have turned Riffims into a fifth disconnected tool were dropped before being designed.
Ten levels, three phases.
Ten levels organized in three phases. Production covers song preparation and visual identity; release covers intellectual property, distributor, campaign and press; post-release covers maintaining momentum and reading metrics. Each level has subtasks, contextual tips, reflection questions and direct access to the AI assistant. Progress is tracked per release, so an artist can have a single at Level 8 and an EP at Level 2 at the same time, with four badges that unlock at milestones along the path.
Why that order.
The sequence is the product. An artist who doesn't know where their project stands today shouldn't be choosing a distributor. Making the fundamental questions unavoidable is what prevents the three failures that sink most independent releases, which are going out without cover art, without intellectual property registration or without a communication plan. That also makes the order the riskiest part of the product. It encodes my assumptions about how artists actually work, and it's the part most likely to be wrong. I come back to this at the end, because that's where the remaining work is.
Three roles, three entry points.
Solo artist, band and manager have different entry points. Solo and band go through six steps. A manager goes through three, because a manager doesn't need to choose their own genres or an artist emoji. Afterwards they manage up to three artist profiles, each with independent releases and mission progress, isolated at the database level and not hidden in the interface.
Teaching instead of explaining.
Level 3 asks the artist for their visual identity, and it's where most people get stuck. Cover art is approved by looking at it large on a computer and judged tiny in a playlist. Cover Preview shows it inside a real player, with up to four versions side by side and the title and name editable live. The decision is the same one that governs the rest of the product. Instead of telling the artist that their cover needs to work small, I show it to them small. Riffims teaches by doing, not by giving advice.
168 tokens, 12 components, zero UI libraries
Angular Material and PrimeNG were reasonable options and I discarded both. Adopting a library means inheriting a visual identity and then fighting it, which for a product built around a specific tone is a bad deal even if the first day is faster.
So the system is custom-built. 168 tokens in SCSS, with a 4px spacing scale, 16 typographic sizes across nine weights, a neutral ramp from 50 to 950, four semantic scales of nine tones each, brand color at #FF5E2D, plus shadows, radii, z-index, transitions and five breakpoints. On top of that, 12 shared components, 7 base and 5 specialized, and 43 SVG icons drawn for this product.
Mobile-first for real, not just in the breakpoints. The bottom navigation on mobile becomes a fixed sidebar on desktop, and Riffi switches from a full page to a side panel. The same information, laid out for the device it's being held on.
This is where what was left half-done in the missions is actually well resolved, because the visual decisions live in the token layer and changing the brand is an edit in one file, not in 55 stylesheets.
The API key never reaches the client
Riffi is the AI assistant, and it's not a chat window glued to one side. It's integrated into the mission flow with three fixed modes, a practical industry tip, a terminology definition and a promotion idea for social media.
The architecture puts the boundary where it belongs. The Angular component calls a Supabase Edge Function on Deno, and that function calls Gemini from the server. The API key never exists in the browser. The context is limited to the last 20 messages, enough to maintain coherence without spending tokens on history nobody needs.
The Riffionary reuses that same boundary for something else. It's a curated dictionary of 53 industry terms in five categories, with debounced search, recent history and popularity ranking. When a term isn't there, an "ask Riffi" button generates the definition through the same Edge Function, and every search is logged in both cases. The dictionary's gaps tell me what to write next, which turns a fallback into a content roadmap.
Underneath are seven PostgreSQL tables with Row Level Security on all of them, chained guards that make it impossible to enter the app without finishing onboarding or return to it once completed, and cascading deletes so that removing an artist profile doesn't leave orphaned releases.
Documentation as the baseline
I worked without a design team, without a product manager and without anyone to challenge a decision before it reached code. Validation came from conversations with independent musicians I know personally, not from usability testing. With three months ahead, writing down the reasoning was what kept each week from starting by second-guessing the previous one.
Over 30 specification documents remain. They're not academic deliverables, they're the product's starting point, because when I come back to rework the mission order or the onboarding I don't start from zero, I start from why I left it that way. It started as a master's thesis at UOC and I built it as a product all the same. That foundation is the reason I have somewhere to go today and not just a completed assignment.
What I cut and what I didn't
The hardest part wasn't the Edge Functions or the RLS. It was cutting. The original vision had a release calendar, push notifications, AI response streaming, conversation persistence and advanced analytics. All of them would have improved the artist's experience, and all of them were dropped. What shipped to production is the mission system, the assistant and the two tools that remove friction immediately.
The rule was simple, cut whatever you need but don't cut the sequence. A release calendar is a good feature inside a product that already teaches you which dates matter. Without the missions, it's a spreadsheet with better typography.
There was one cut that wasn't about scope but about architecture, and it's the one that carries the most weight today. The ten missions live as typed constants in TypeScript. It's what allowed me to ship in three months with consistent content and end-to-end type safety. It's also the decision that limits the product the most right now, and that's where the next work comes from.
None of these cuts became hidden debt. They became a written roadmap, which is something else entirely.
Measurable Impact
3
months from zero to production, in 10 sprints
168
design tokens, plus 12 shared components and 43 icons
7
PostgreSQL tables, with Row Level Security on all
0
external UI libraries
Making the product able to iterate
Riffims is in production, but the order of the ten levels is still my hypothesis. I designed it from conversations with musicians and from how the industry works, not from usage data. Ten levels might be too many for a single and too few for an album. Six onboarding steps might be too many before letting anyone see anything. I don't know yet, and today the product can't find out quickly. The mission content lives in typed constants, so changing one word of a tip is a deploy, and running two versions of the path with two groups of artists is impossible.
The next step is moving that content to the database, with versioning. A tip, a subtask or the order of two levels stops being something you deploy and becomes something you edit, measure and test. Then the numbers can start, completion rate per level, where people drop off, how often the Riffionary falls back to Riffi. Those tell me which of these decisions I got right and which I guessed. The rest is already written down, from response streaming to WCAG AAA.
Riffims is an MVP and I treat it as one. What comes next is to keep researching, designing and developing until it's a tool that removes noise from making music and explains the industry to anyone who wants a career in it. I've walked that path and I watch the people I love most walk it every day. That's why this project doesn't end with the delivery.