MATKIN por dentro: Cómo construí en solitario un pasaporte digital para BJJ con React 19, Capacitor y Supabase
Hace un par de años, en uno de mis posts de favoritos, subí un pequeño dibujo que resumía bastante bien mi relación con las ideas propias: tengo una idea, empiezo a darle forma, se la cuento a alguien, se me ocurre otra… Y el bucle vuelve a empezar sin terminar ninguno de esos «locos proyectos».
Con MATKIN decidí romper ese bucle. No solo porque el Brazilian Jiu-Jitsu (BJJ) se haya convertido en mi vía de escape para desconectar de pantallas, que también, sino porque veía cada semana en el vestuario el mismo problema sin resolver. Sales de entrenar, has hecho cinco o seis rolas buenas, comentas la jugada con los compañeros… Y al día siguiente ya nadie se acuerda de qué trabajó ni de cómo evoluciona a lo largo del año.
Total, que me lié la manta a la cabeza para diseñar y programar de principio a fin MATKIN: un pasaporte competitivo para luchadores de BJJ y una herramienta de gestión para academias. Y hace unos días nos seleccionaron en Telefónica Open Future (Andalucía Open Future)… Pero bueno, antes de contar lo bonito, vamos a ver qué hay debajo del capó y qué cuesta sacar esto adelante en solitario.
El problema real: del tatami a la base de datos (y la batalla de la activación)
La idea sobre el papel sonaba sencilla: aplicar un sistema matemático de puntuación ELO (como el del ajedrez) a los combates de entrenamiento diario y sumarle un ranking para academias (MAP — MATKIN Academy Points) donde pese tanto el nivel del Top 5 por cinturón como el tamaño de la cantera.
Ahora bien, cuando bajas al barro del producto real te das de bruces con dos muros muy distintos:
1.- El muro técnico: calcular rankings dinámicos por cinturón, peso y academia desde el móvil sin freír la batería ni bloquear la interfaz cuando la cobertura dentro de un gimnasio (que suele ser un sótano o una nave) es pésima.
2.- El muro humano: convencer a la gente (o que se acuerden después de sudar el kimono) de registrar sus luchas. Hoy tenemos unos 550 usuarios registrados y el sistema de control de asistencia funcionando ya en academias reales, pero lograr que el hábito de registrar cada combate cuaje en el día a día cuesta horrores. Habrá que seguir peleando.
Decisiones de arquitectura: React 19, Capacitor y el trabajo sucio en PostgreSQL
Cuando diseñas y programas tú solo apoyándote en la IA (que sigue siendo «una tostadora», nos hace mucho más rápidos pero el criterio de qué construir y cómo no romper producción sigue siendo 100% tuyo), la tentación es meter demasiadas piezas. Yo tiré por el camino más pragmático posible:
1. Una sola base de código e infraestructura nativa bajo control Git
Monté el frontend con React 19, Vite y Tailwind CSS v4 bajo un sistema de diseño propio (DS-V2: radio estricto de 4px, cero cajas dentro de cajas para ganar aire en pantallas pequeñas y cero emojis).
Para bajar a iOS y Android utilicé Capacitor. Eso sí, tomé una decisión que va en contra de lo que suelen recomendar muchos tutoriales: versionar las carpetas nativas /android e /ios directamente en Git. ¿Por qué? Porque cuando en mitad de las pruebas en Android te salta un fallo intermitente de red (Remote host terminated the handshake) por cómo negocia Gradle el protocolo TLS en redes móviles, y tienes que inyectar a mano en android/gradle.properties:
systemProp.https.protocols=TLSv1.2,TLSv1.3
…lo último que quieres es que un despliegue limpio en la nube te borre el parche.
2. Delegar las matemáticas a Supabase (RPCs y RLS estricto)
En lugar de traer cientos de registros al teléfono para calcular puntos en JavaScript, toda la lógica pesada vive en procedimientos almacenados (PostgreSQL RPCs) dentro de Supabase:
- La función
get_academy_rankingscruza en menos de 40 milisegundos el ELO de los luchadores, filtra por cinturón y pondera la cantera. - Todas las tablas tienen políticas Row Level Security (RLS) activas, incluyendo una regla de ghosting mutuo: si un usuario bloquea a otro para evitar malos rollos, ambos desaparecen mutuamente de sus radares y rankings.
3. Protocolo «Cero Errores» y fin de las pantallas congeladas
No hay nada que dé más rabia en una app móvil que quedarte mirando un spinner infinito porque se ha cortado el 4G en el vestuario. Establecí dos reglas innegociables en todo el repositorio:
- Ningún texto va escrito a fuego en el código; todo pasa por archivos de traducción (
ES,EN,PT,FR,IT). - Toda llamada asíncrona va envuelta en su
try / catch / finally, apagando siempre el estado de carga (isLoading = false) en elfinally. Sin excepciones.
Mi propio «equipo» de operaciones: MATKIN Enterprise OS y Alfred
Claro, llevar el diseño de producto, el código, las visitas a los dojos, las finanzas y el SEO entre semana (mientras cumples con tus dailies y sprints en el trabajo y estás con la familia) tiene truco.
Para no perder el contexto entre sesiones creé dos piezas que han cambiado por completo mi manera de trabajar:
- El protocolo documental
Alfred: Una base de más de 140 documentos Markdown dentro del propio repositorio (/docs) que funciona como única fuente de verdad. Ningún agente de IA toca una línea de código sin leer antes el contrato de arquitectura ni cierra una tarea sin actualizar el historial. - MATKIN Enterprise OS (
/ops): Un sistema multi-agente organizado por departamentos (Dirección, Finanzas, Marketing/GEO, Comercial y DevOps) conectados por un bus de eventos. Si cambian los costes fijos mensuales (~306 €/mes de infraestructura y servicios), el agente financiero recalcula el punto de equilibrio (que tenemos en solo 7 academias de pago) y ajusta los objetivos sin que yo tenga que abrir una hoja de cálculo.
El cambio en velocidad y control ha merecido, y mucho, la pena.
