Financial Control Center

Un saldo bancario no responde cuánto dinero se puede gastar: ignora compromisos, deuda, ahorro reservado y movimientos planificados. El producto nace para convertir esas reglas en una lectura financiera honesta.

Proyecto personal: nació para resolver un problema mío y lo diseñé y construí desde cero. Sigue en desarrollo. El repositorio incluye una aplicación funcional con datos de demostración, documentación de arquitectura y pruebas de invariantes financieros sobre PostgreSQL real.

Construir un centro de control que permita entender el disponible real, registrar operaciones sin romper el historial y evolucionar el dominio de forma incremental.

• Definí el producto, el lenguaje del dominio, la experiencia visual y la arquitectura full stack.
• Modelé el dominio en Prisma (23 modelos y 17 enums), con restricciones documentadas entre base de datos y capa de negocio.
• Implementé autenticación, persistencia, casos de uso, interfaz responsive, datos demo y pruebas automatizadas.

• Next.js 16 con Server Components y Server Actions; PostgreSQL es la fuente de verdad y Prisma la capa de persistencia.
• Better Auth usa el mismo User del dominio y renombra su Account para no colisionar con la cuenta financiera.
• Las escrituras que afectan varias entidades usan transacciones; Zod valida las reglas que PostgreSQL no puede expresar.
• 23 ADRs registran decisiones sobre dominio, seguridad, autenticación, estado, tema y pruebas.

• Implementado: cuentas, movimientos, crédito y cuotas, planificación, presupuestos, ahorro, préstamos, conciliación, reglas, resumen y análisis.
• Implementado: registro rápido, temas claro/oscuro/sistema, dataset demo determinístico y aislamiento de datos por usuario.
• En desarrollo: despliegue público y refinamiento de los flujos completos con datos reales.
• Planificado: ingreso de transacciones mediante lenguaje natural como una capa sobre casos de uso validados, no como escritura directa en la base.

• Distinguir saldo, disponible, deuda, gasto, ahorro y reembolso sin duplicar fuentes de verdad.
• Mantener historial auditable: los movimientos se anulan en vez de borrarse y los valores sensibles se derivan al leer.
• Priorizar exactitud del dominio sobre abstracciones prematuras; no se añadió un repositorio genérico ni estado global en V1.

• El modelamiento del dominio y las invariantes cambian más el producto que una pantalla aislada.
• Probar reglas financieras contra PostgreSQL real descubre errores que un mock no representa.
• Los ADRs hacen visible el proceso de ingeniería y permiten revisar decisiones cuando el producto evoluciona.