RiffLead

Contact and relationship management for artist management teams. The deals, follow-ups, and industry relationships that run a roster — in one place instead of six.

The home view: pipeline, reply rate, and the follow-ups that are about to slip — front and center.

Management is a relationships business run out of spreadsheets.

I came out of the music industry, and I watched how artist management actually operates day to day: the roster lives in one spreadsheet, the contacts in another, the deal terms in someone's email, and the follow-ups in whoever's head remembered them. Generic CRMs don't fit — they're built for sales pipelines, not for the long, slow relationship work of managing artists.

RiffLead is the version of that tool built by someone who's seen the workflow from inside: who you know, what's in motion with them, and what needs to happen next — shared across the team instead of trapped in one person's DMs.

One shared picture of the roster

Contacts with history. Every industry contact in one place, with the relationship context attached — not just a name and an email.

Deals and follow-ups. What's in motion, who owns it, and what the next step is, so nothing dies in an inbox.

Built for teams. Management is rarely one person. The whole team works from the same data, scoped so each team sees its own roster and nothing else.

Where it fought back

RiffLead is a multi-team app, and multi-team is where AI-generated code quietly betrays you.

The database was too open — mine included

The security pitch on this site isn't secondhand. Early in RiffLead's development, row-level security wasn't locking things down the way it needed to — data that should have been scoped to one management team was reachable with the public anon key. In a CRM, that's not a cosmetic bug; that's other people's business relationships.

The fix was unglamorous: policies rewritten table by table, scoped to the team rather than just the user, then re-tested the way an attacker would — by taking the public key and trying to read everything. That test — "don't check the setting, attempt the read" — is now literally a feature of Ms. Vibecode.

Auth that worked until it didn't

Sign-in worked on day one, which is exactly the trap. In real use, sessions dropped and redirects misbehaved — the class of bug that never shows up in a demo and always shows up for a real user on a Tuesday. Fixing it meant tracing the auth flow end to end and actually understanding it, instead of trusting that generated code that runs is code that's finished. That distinction — runs vs. finished — is most of what my client work is.