La pregunta que ninguna planilla me contestaba
Hay una pregunta que casi nadie se atreve a escribir en voz alta: ¿me alcanza para los próximos doce meses? Y la versión más honesta de esa pregunta no es “¿cuánto tengo hoy?”, sino “¿cuándo cruzo a tierra firme?”.
Llevaba meses respondiéndola a mano, en una planilla que arrastraba supuestos como quien arrastra cajas de una mudanza: a tirones, perdiendo cosas por el camino. Así que esta semana construí y dejé en producción un copiloto financiero personal —privado, solo para mí— que proyecta mis finanzas a doce meses y me responde una sola cosa con claridad: si llego, y cuándo dejo de ir cuesta arriba.
No es una app para vender. Es una herramienta para vivir mejor. Y como todo lo que hago en la corporación, te cuento cómo se construyó —los desvíos incluidos— sin enseñarte un solo número de mi vida.
El pipeline dijo “no”. Lo construí igual (y por qué eso importa)
El proyecto pasó por la mesa de agentes de siempre. Y la primera respuesta fue incómoda: Wags, el estratega, dio DEFER. Su argumento era impecable y duele porque es verdad: el cuello de botella de un producto no es construirlo, es distribuirlo. Lo aprendimos a sangre con LabelLoop. Construir es la parte fácil; que importe es la difícil.
Hice un override consciente. No porque Wags se equivocara, sino porque esto no era un producto: era una necesidad personal con fecha de vencimiento. Build in public también es esto —mostrar cuándo decides ir contra el consejo de tu propio equipo, y asumir que la cuenta llega después.
De ahí el resto bajó al ruedo: Oracle midió viabilidad y riesgo, Saul cuidó la marca, Steve cerró el PRD, Ive diseñó, Porat —el CFO— validó que la matemática no mintiera, Cialdini afiló cada palabra de la interfaz, Logan partió el trabajo en tickets, The Architect auditó seguridad y Neo escribió el código. Diez especialistas para una herramienta que, en el papel, “solo” suma y resta. Spoiler: nunca era solo sumar y restar.
La decisión técnica de la que estoy orgulloso: ningún número sin explicación
La tentación, con una herramienta financiera, es esconder la fórmula. Hacer que el resultado parezca magia. Hice exactamente lo contrario.
El motor de cálculo se reescribió como un grafo de cómputo (un DAG): cada valor declara de qué otros valores depende, con qué fórmula se obtiene y —esto es lo importante— de qué supuesto o fuente nace. Ningún número existe huérfano. Si te muestro un resultado a doce meses, puedo abrirlo y mostrarte el camino completo que lo produjo, paso a paso. “Explícame esto” deja de ser una promesa de marketing y pasa a ser una función real.
¿Por qué tanto esfuerzo en algo invisible? Porque una proyección en la que no confías no la usas. Y una que no usas, no te cambia nada.
El principio anti-Goodhart: te muestro lo que ahorras de verdad
Acá hay una sutileza que me importa más que el código. Cuando sacas del cálculo un gasto que compartes con alguien, la tentación es mostrar el monto completo como ahorro. Se siente bien. Y es mentira.
La herramienta muestra el ahorro neto real —solo tu parte—, nunca el bruto. Porque si te muestro el bruto, te hago creer que ahorras el doble de lo que ahorras, y una herramienta que te miente para que te sientas bien es peor que no tener herramienta. La métrica existe para guiarte, no para acariciarte. En cuanto una métrica se convierte en el objetivo, deja de ser una buena métrica. Esto es eso, llevado a una línea de cálculo.
Privacidad de verdad, no de folleto
Lo digo claro porque la confianza se construye en los detalles aburridos:
- Acceso cerrado por lista de correos autorizados.
- Cada persona ve solo su propio modelo. Aislamiento estricto a nivel de base de datos: tu proyección es tuya y de nadie más.
- Cero cifras reales en el repositorio. El código sabe cómo calcular; jamás conoce qué calculas tú.
Los desvíos (porque esto es build in public, no un currículum)
Nada de esto salió derecho. Tres tropezones que valen más que el resultado limpio:
- El slider que redondeaba. Un control deslizante “redondeaba” un valor por debajo y descuadraba la proyección entera. Un error chico que envenenaba todo lo de aguas abajo —el costo de un DAG es que un nodo malo contamina la cadena. La virtud del DAG es que también te deja encontrarlo rápido.
- Los campos que se borraban solos. Al agregar un gasto, los campos de ingreso se vaciaban. Faltaba sincronizar el estado. El clásico bug que no rompe nada técnicamente pero rompe la confianza al instante.
- La tabla desalineada. Un detalle de alineación que solo se cazó con un repro visual, mirando, no leyendo logs. A veces el bug no está en la lógica, está en el ojo.
Ninguno es glamoroso. Todos son reales. Y esa es la diferencia entre documentar código y escribir el diario honesto de cómo se construye algo.
Quiero que lo pruebes
Lo dejé en una beta privada y cerrada. Si quieres proyectar tus propios doce meses —con tu sueldo, tus bonos, tus deudas y tus gastos reales— escríbeme un DM por LinkedIn y te doy acceso. Cada persona entra a su propio modelo, aislado y privado: tus números son tuyos y de nadie más.
El titular no es la herramienta. Es lo que te devuelve.
La herramienta es un medio. Lo que me devolvió fue dormir distinto: saber con números honestos —no optimistas, honestos— cuándo dejo de ir cuesta arriba. Eso no se compra. Se construye. Y, cuando se puede, se comparte.