Cronos Cashflow
Plataforma de planificación financiera y visibilidad de flujo de caja: compromisos futuros, movimientos recurrentes y proyecciones.
Contexto
Producto propio. Una plataforma de planificación financiera pensada para dar visibilidad sobre obligaciones futuras, movimientos recurrentes y proyecciones de flujo de caja, el tipo de información que suele vivir dispersa en hojas de cálculo.
Desafío
El dominio financiero no tolera ambigüedad: un movimiento recurrente mal proyectado corrompe toda la previsión. El reto es modelar recurrencia, proyección y realizado de forma que el número en pantalla sea auditable hasta su origen.
Mi papel
Arquitectura de software, desarrollo backend y frontend, modelado del dominio financiero, autenticación, despliegue e infraestructura.
Responsabilidades
- Arquitectura de software y modelado del producto.
- Backend en PHP 8 y base de datos relacional.
- Interfaz web en Next.js.
- Autenticación y control de acceso.
- Despliegue e infraestructura en contenedores.
Restricciones
- La corrección del dominio financiero por encima de la velocidad de entrega.
- La autenticación debe servir a tres clientes distintos: web, aplicación móvil y la aplicación heredada.
- Producto propio con un equipo reducido: la arquitectura debe caber en quien la mantiene.
Arquitectura
- Backend organizado en módulos separados (aplicación, API, biblioteca común y capa de consola), con la consola alojando rutinas y comandos programados.
- Autenticación por JWT, sirviendo web y aplicación móvil desde la misma API.
- Interfaz web desacoplada que consume la API, con el dominio separado de la presentación.
- Aplicación móvil en React Native compartiendo la misma API del backend.
- Entorno en contenedores con Docker y docker-compose.
Principales decisiones técnicas
Mantener un único backend sirviendo a web y móvil, en lugar de dividir en servicios.
Por qué
El dominio es cohesivo y el equipo es pequeño. Un monolito modular bien organizado ofrece la misma claridad de fronteras sin el coste operativo de distribuir el sistema.
Trade-offs
- Escalado vertical antes que horizontal.
- Exige disciplina interna de módulos. Sin ella, el monolito se convierte en una bola de barro.
- Reduce drásticamente la superficie de operación: un despliegue, una base de datos, un sitio donde depurar.
Autenticar con JWT en lugar de sesiones de servidor.
Por qué
La misma API sirve a un navegador y a una aplicación móvil. La sesión con cookie funciona bien en el navegador y mal en móvil; JWT da un mecanismo único para ambos clientes.
Trade-offs
- La revocación de token exige una estrategia propia: no basta con destruir la sesión.
- El token necesita una vida corta, lo que trae la complejidad de la renovación.
- A cambio, un único flujo de autenticación para todos los clientes.
Modelar la recurrencia como regla, no como filas pregeneradas.
Por qué
Materializar años de movimientos futuros en la base de datos congela la edición: cambiar una recurrencia obligaría a reescribir todo el histórico proyectado.
Trade-offs
- La proyección pasa a calcularse, lo que cuesta más en lectura.
- Exige cuidado con las excepciones puntuales dentro de una serie recurrente.
- A cambio, alterar la regla se refleja de inmediato en toda la proyección.
Implementación
- Movimientos financieros recurrentes y puntuales.
- Proyección de flujo de caja a partir de las reglas de recurrencia.
- Dashboards e informes financieros.
- Control de acceso por rol.
- Integración de pagos vía Stripe.
Operación en producción
- Despliegue en contenedores.
- Rutinas programadas ejecutadas por la capa de consola del backend.
- Operación y soporte bajo responsabilidad propia.
Resultados
- Producto en producción, con web y aplicación móvil servidas por la misma API.
- Convirtió las reglas de recurrencia en visibilidad anticipada de compromisos futuros, sustituyendo el control manual en hoja de cálculo.
- Una única superficie de autenticación para los distintos clientes del producto.
Stack
- PHP 8.3
- MySQL
- JWT
- Stripe
- Next.js
- React
- TypeScript
- Tailwind CSS
- React Native
- Docker