Por qué existe este sistema y cómo decidimos qué construir.
Operamos una empresa de suscripciones a ciegas: no sabemos cuánto cobramos que sea realmente de Gonama, cuánto gastamos, cuál es el margen, ni en qué estado está cada cliente. Y está agravado porque la cuenta de PayPal es compartida con Jinkanna, así que ni siquiera podemos separar la plata de cada empresa.
Clientes activos
8
mayo 2026
MRR efectivo
USD 705
por mes
Costos
USD 1330–1400
por mes
Resultado
− USD 625 a 695
break-even con 4 o 5 del plan Carrito
Lannot estuvo 60 días con pagos fallidos que nadie vio, hasta que aparecieron en un análisis manual el 28 de mayo. PayPal canceló la suscripción al día siguiente.
El cliente quería seguir: armó una suscripción nueva el 29 de mayo y pagó otra vez los USD 400 de setup que no tendría que haber pagado. Si el sistema hubiera avisado del primer fallo, no pasaba nada de esto.
Cuánto facturamos para Gonama específicamente y no mezclado con Jinkanna. Cuánto es recurrente y cuánto es setup de una sola vez. Cuánto es plata real y cuánto se devolvió. Qué clientes pagan y cuáles están fallando ahora mismo.
Cuánto cuesta la infraestructura: Amplify, fly.io, AWS, Sentry, Sonetel, Wondershare, el hosting de Shopify. Cuánto cuesta Renato de verdad, que Jinkanna se lo cobra a Gonama. Cuánto vale el tiempo de Fierro, que figura como "inversión Jinkanna". Y cuánto se va en apps de clientes que ya no son clientes.
La cuenta merchant info@jinkanna.com procesa cobros de Gonama, cobros de Jinkanna y pagos a herramientas, todo junto. No podemos separar qué entró a cada una, ni cuánto le debe Gonama a Jinkanna por los servicios, y el cashout se hace sin atribuirle el monto a nada.
Cuál está sano y cuál en riesgo. A cuál le falló un cobro y hace cuántos días. Cuál está suspendido pero se podría recuperar, como Don Gato Kids. Y cuál se fue hace rato pero le seguimos pagando la infraestructura.
Como consecuencia de lo anterior, las decisiones grandes —seguir invirtiendo, expandir a Perú o Argentina, apagar apps, constituir Gonama legalmente— se toman sin números reales.
Gonama nunca se constituyó como entidad legal propia. Opera bajo Jinkanna.
Se arrancó pragmáticamente usando info@jinkanna.com como cuenta merchant de PayPal.
No hay protocolo de atribución: cuando entra un pago a PayPal, nadie lo etiqueta.
El seguimiento de clientes es informal. NF lo hace cuando se acuerda, sin sistema.
No había herramientas propias. Hasta el admin: el dashboard de PayPal, Excel y WhatsApp.
El contrato 50/50 nunca se firmó. La sociedad es de palabra.
El equipo está distribuido y no tiene una fuente de verdad compartida.
Jinkanna le vende servicios a Gonama pero nunca se formalizó como una cobranza constante. No sabemos cuánto habría que haber cobrado acumulado — es el rojo invisible.
Dos socios: Nicolás Fernández 50 % y Jinkanna 50 %, sin contrato firmado
→ La solución tiene que ser auditable por los dos
Gonama todavía no es una entidad legal
→ No se abre una cuenta de PayPal nueva por ahora
La cuenta de PayPal es compartida
→ La separación tiene que hacerse por software
Renato no trabaja en el admin — es el dev del producto
→ El admin lo construye Alexander
Gonama está en rojo
→ El sistema tiene que costar menos de USD 15 al mes
Hay solo 8 clientes activos
→ La prioridad es no perderlos, no escalar
El equipo está distribuido
→ Tiene que ser web
NF tiene poco tiempo
→ El sistema tiene que avisar solo, no esperar que le pregunten
Todo el diseño se apoya en una idea: el sistema consume los datos en vivo —PayPal sobre todo—, detecta lo que cambió, le sugiere una acción al operador, y el operador confirma.
Aparece una suscripción nueva en PayPal y el sistema pregunta "¿doy de alta este cliente?". Entra un cobro y el sistema propone "esto parece MRR de Gonama". Un click y listo. Aplica a todo el sistema, no solo a los clientes.
El State of Gonama, escrito en mayo de 2026, proponía construir el admin como una de varias decisiones pendientes. Textual: resolvía "dunning automático + customer success básico + visibilidad financiera", estimado en dos o tres semanas part-time de Renato.
Es decir: el admin atacaba un nudo específico. No era una plataforma de gestión integral.
Lo que se ejecutó fueron entre 8 y 12 semanas full de Alexander, y Renato nunca lo tocó. Al validar lo construido contra la necesidad real apareció el problema que originó esta revisión: se construyó bastante más de lo que hacía falta.
Salió del alcance a propósito. Si algo de esto reaparece, es un error.
Los requerimientos salen del negocio, nunca del código. Si uno se "descubre" leyendo lo que ya está construido, está contaminado: justifica lo que existe en vez de medir si sirve.
Cada etapa se cierra antes de empezar la siguiente, y se cierra con una confirmación explícita.
El estado de un requerimiento tiene dos pasos, no uno. Primero Claude dice que está en el código: eso lo pone en "por validar". Después Alexander lo prueba contra los criterios de aceptación y confirma: recién ahí queda "listo". Que exista el código no alcanza.
Todo esto —los requerimientos, el estado, lo que escribamos sobre cada uno— vive en el repositorio y se versiona con git. Esta sección es de solo lectura: lo que ves acá es el archivo.