El problema

Les acadèmies d’arts marcials es gestionen, gairebé sempre, amb eines que no van ser pensades per a elles: fulls de càlcul per al llistat d’alumnes, una llibreta per als cobraments, missatgeria solta per als avisos i el cap del professor per a tota la resta. Funciona fins que deixa de funcionar. Quan el gimnàs creix, cada mensualitat sense cobrar, cada cinturó sense registrar i cada assistència sense apuntar es converteix en feina manual que roba temps al tatami.

El programari genèric de gestió de gimnasos tampoc no encaixa: ignora el que fa específiques les arts marcials —graus i cinturons, progressió tècnica, seguiment per disciplina— i obliga a doblegar processos perquè càpiguen en un motlle de “fitness”.

El rol — fundador en solitari

MojoDojo l’he construït jo sol, de punta a punta: producte, arquitectura, backend, frontend, base de dades, cobraments i desplegament. És un projecte propi (SaaS en solitari, no cofundat), la qual cosa va significar decidir l’abast amb la mateixa disciplina amb què s’escriu el codi: enfocar-me en el que un gimnàs real fa servir cada dia i deixar fora tota la resta.

El procés

Partir d’un gimnàs real. El producte no va néixer d’una hipòtesi de mercat, sinó de l’ús diari d’una acadèmia concreta. Això va fixar les prioritats: primer allò que es toca cada setmana —alumnes, assistència, cobraments—, després l’accessori.
Iterar amb l’usuari a dins. En tenir el gimnàs en producció des de ben aviat, cada funcionalitat es va validar contra ús real, no contra una maqueta.
Triar un stack avorrit i sòlid. Go per a un backend predictible, React per a una interfície que professors no tècnics fan servir sense fricció, PostgreSQL com a font de veritat i Stripe per no reinventar els pagaments ni carregar amb dades sensibles de targeta.
Abast disciplinat. En ser un projecte en solitari, cada funcionalitat s’havia de guanyar el seu lloc. La regla: si el gimnàs no ho necessita aquesta setmana, encara no entra.

La solució

MojoDojo és un SaaS de gestió per a acadèmies d’arts marcials que reuneix en un sol lloc el que abans estava repartit entre fulls de càlcul, llibretes i missatges:

Gestió d’alumnes i les seves dades.
Seguiment d’assistència i de progressió per graus/cinturons.
Cobraments de quotes recurrents via Stripe.
Interfície pensada perquè la faci servir el personal del gimnàs, no un administrador de sistemes.

L’objectiu de disseny va ser que l’eina desaparegui: menys temps davant d’una pantalla, més temps al tatami.

Resultats

En producció en un gimnàs real, amb ~300 usuaris. No és una demo ni un pilot: és l’eina amb què una acadèmia opera el seu dia a dia.
Substitueix l’apedaçat de fulls de càlcul i cobraments manuals per un únic sistema.

Aprenentatges

Un usuari real val més que deu entrevistes. Tenir un gimnàs en producció va convertir cada decisió en una hipòtesi comprovable.
L’abast és la funció més difícil d’un fundador en solitari. Sense equip, dir “no” a temps és el que manté el projecte viu i mantenible.
“Avorrit” és una virtut en infraestructura. Go + PostgreSQL + Stripe signifiquen menys sorpreses a les 3 de la matinada.
Especialitzar-se guanya a generalitzar. Parlar l’idioma de les arts marcials —cinturons, graus, disciplines— és justament el que el programari genèric no fa.