Royalties Calculator: ho trasformato il foglio Excel più odiato della mia label in un prodotto

C'è un momento, in ogni label indipendente, che si ripete identico ogni trimestre. Arriva lo statement del distributore. Lo apri. È un CSV con decine di migliaia di righe, una colonna per ogni store, una valuta che cambia, nomi di artisti scritti in tre modi diversi. E davanti hai una sola domanda, semplice da porre e fastidiosa da rispondere: quanto spetta a ciascun artista?

La risposta, per anni, è stata la stessa: Excel. Copia, incolla, formule annidate, una percentuale battuta a mano, il controllo incrociato perché un errore qui significa pagare male qualcuno. Poi il mese dopo si ricomincia da capo.

Conosco quel rito da dentro, lavorando su Tosky Records. A un certo punto ho smesso di considerarlo un costo inevitabile e ho iniziato a trattarlo per quello che era: un problema di prodotto. Da lì è nato Royalties Calculator.

Il problema, definito con precisione

Prima di scrivere una riga di codice ho scritto cosa doveva fare, e soprattutto cosa non doveva fare. Il rischio, quando costruisci uno strumento per te stesso, è di replicare in software il tuo flusso personale invece di risolvere il problema vero.

Il problema vero erano tre passaggi che facevo a mano ogni volta: normalizzare statement che arrivano in formati diversi da distributori diversi, applicare gli split contrattuali per artista (e, quando serve, le quote editoriali di compositori e autori), produrre un documento presentabile da consegnare all'artista.

Tre passaggi, tre fonti di errore, zero margine. La definizione del prodotto è uscita da qui.

Le scelte tecniche, e perché

L'app è un monorepo. La logica di calcolo vive in un pacchetto separato, il royalty-engine, con i suoi test. Non è un dettaglio estetico: il motore che decide quanti soldi spettano a una persona è esattamente il punto in cui non puoi permetterti regressioni silenziose. Tenerlo isolato e testato significa poter cambiare l'interfaccia senza toccare la matematica, e viceversa.

La normalizzazione degli statement è un secondo pacchetto dedicato, con preset per 12 distributori e un mapping guidato delle colonne che prova a indovinare lo schema da solo, lasciando comunque all'utente l'ultima parola. Qui ho imparato la lezione più utile del progetto: i dati del mondo reale sono sporchi, e l'unico modo onesto di gestirli è progettare per l'eccezione, non per il caso ideale.

Lo stack di superficie è quello che uso ormai per i prodotti che devono stare in piedi da soli: Next.js e TypeScript per l'app, Clerk per l'autenticazione e le organizzazioni multi-tenant (ogni label ha il suo spazio e il suo brand), Stripe per la monetizzazione, database serverless su Neon, storage su Vercel Blob per logo e firme. L'interfaccia parla quattro lingue — italiano, inglese, francese e spagnolo — perché il mercato editoria musicale non è italiano.

Una scelta su cui ho ragionato a lungo è il modello di prezzo. Niente abbonamento: crediti a consumo. Una label non usa uno strumento di royalties tutti i giorni, lo usa quando arrivano gli statement. I crediti seguono l'uso reale: importi, calcoli, esporti, paghi quei gesti.

L'AI dove serve, non dove fa scena

C'è un'integrazione AI, ma volutamente al margine. Nell'export PDF posso aggiungere un blocco di insight generato da un modello di reasoning, arricchito con contesto preso da fonti pubbliche. È un di più, non il cuore del prodotto. Il cuore è un calcolo deterministico che deve essere giusto al centesimo. Mettere un modello generativo nel punto in cui si decidono i pagamenti sarebbe stato esattamente l'errore da non fare.

Cosa significa "in produzione"

Royalties Calculator non è un progetto da portfolio fermo a uno screenshot. È online, su royalties-calculator.labeltools.app, con autenticazione di produzione, pagamenti reali e utenti che lo usano. Fa parte di LabelTools, la suite di strumenti per produttori, editori e artisti che sto facendo crescere, accanto al Press Review Tool per il monitoraggio della rassegna stampa.

La differenza tra una demo e un prodotto in produzione la fanno le cose poco fotogeniche: i rate limit sulle API, lo storage privato con URL firmati per logo e firme, il trial legato all'IP per evitare abusi, la migrazione del database versionata. Nessuna di queste finisce in un post entusiasta, ma è la somma che distingue qualcosa che funziona da qualcosa che sembra funzionare.

Cosa mi ha insegnato

Costruire uno strumento per un problema che vivi in prima persona è un vantaggio e una trappola. Il vantaggio è che conosci ogni asperità del flusso. La trappola è che rischi di codificare le tue abitudini invece del bisogno generale. Il salto, ogni volta, è chiedersi se quello che stai automatizzando serve solo a te o serve a chiunque faccia quel lavoro.

Per me questo progetto è anche la prova di una tesi su cui costruisco la mia attività: l'AI e il software ben fatto danno il meglio quando entrano in processi reali, con vincoli di costo, affidabilità e manutenzione, non quando inseguono l'effetto. Royalties Calculator è nato così, da un foglio Excel che odiavo. Adesso quel foglio non lo apre più nessuno.

Prossimo passo

Prova l'app: royalties-calculator.labeltools.app

Il case study tecnico con screenshot e stack è in Progetti AI → Royalties Calculator. Se costruisci prodotti o gestisci una label e vuoi parlarne, scrivimi o iscriviti alla newsletter.

---

Giorgio Lovecchio · giorgiolovecchio.com

Tag: SaaS, Music Business, Next.js, Royalties, LabelTools, Product Development