Cómo construí una app de finanzas familiares real (sin saber programar) al mudarme con mi pareja

El Excel que empezó a crujir

Cuando me mudé a vivir con mi pareja, una de las primeras conversaciones serias que tuvimos no fue sobre decoración ni sobre quién friega los platos. Fue sobre dinero: cómo gestionar los gastos comunes, quién paga qué y cómo repartir.

Como buen perfil de negocio, mi primera reacción fue la de siempre: abrir un Excel. Columnas para categorías, filas para transacciones, una pestaña por mes. El clásico. Aguantó exactamente tres semanas.

El problema no era la hoja de cálculo en sí, sino la fricción del día a día: olvidarme de apuntar el supermercado, no encontrar la pestaña correcta o romper fórmulas por error al cuadrar el mes. Las apps de finanzas existentes tampoco encajaban: o eran demasiado genéricas, o exigían vincular cuentas bancarias (no, gracias), o cobraban suscripciones mensuales por funciones que no necesitábamos.

La alternativa lógica era evidente: ¿por qué no construirla nosotros mismos?

De “necesito una app” a “tengo un repositorio en GitHub”

Hace un año, esa idea habría sido inviable. Yo no soy programador. Vengo del mundo de marketing y Revenue Operations, y uso la IA como herramienta de construcción bajo la mentalidad del Director de Orquesta: no necesito dominar la sintaxis de cada lenguaje; necesito tener claro cómo debe encajar la pieza completa.

Mi entorno de trabajo principal es Claude Code. Y de esa necesidad doméstica nació Family Finances (se abre en una pestaña nueva): una aplicación web completa desplegada en Vercel, con base de datos real en PostgreSQL y autenticación con Supabase.

No es una prueba de concepto ni un juguete: es la herramienta que usamos en casa a diario para gestionar nuestro presupuesto.

Además, el repositorio está estructurado para que cualquiera pueda clonarlo, configurarlo en pocos minutos o usarlo como base para sus propias necesidades.

Qué hace Family Finances

Más allá del stack, lo importante es el problema práctico que resuelve:

• Wizard de configuración inicial: Al entrar por primera vez, define nombre del hogar, idioma, moneda, zona horaria y miembros de la familia.
• Presupuestos mensuales por categoría: Asignas límites para supermercado, ocio, transporte… y la app compara en tiempo real el gasto actual frente al presupuesto.
• Dashboard con resumen visual: El gasto del mes frente al presupuesto, una gráfica de ritmo acumulado (¿vamos por encima o por debajo de un gasto uniforme?), ingresos, margen y gasto por persona.
• Entrada manual de transacciones: Manual de forma intencionada. Queríamos que registrar un gasto fuese un acto consciente, no invisible.
• Importación de CSV: Extractos de Revolut, tanto en español como en inglés, con detección de duplicados aunque el banco renombre el comercio entre exportaciones.
• Auto-categorización que aprende: Las reglas siguen mandando (si el concepto contiene “Mercadona”, va a Supermercado), pero ahora la app también aprende de cada movimiento que categorizas y propone categorías para comercios nuevos.
• Bandeja de revisión: Las sugerencias con confianza media no se aplican solas; esperan en una pestaña “Por revisar” para aceptarlas, cambiarlas o descartarlas.
• Reportes mensuales y anuales: Evolución y tendencias de gasto a lo largo del tiempo.
• Soporte bilingüe: Español e inglés adaptado a cada configuración regional.

El stack: decisiones de producto, no de ingeniero

La arquitectura técnica detrás del proyecto:

• Next.js 16 con React 19
• TypeScript de extremo a extremo
• Drizzle ORM para la capa de datos
• PostgreSQL como base de datos
• Supabase Auth para autenticación
• Tailwind CSS 4 para estilos
• Zod para validar cada petición a la API
• Vitest y GitHub Actions para tests e integración continua
• Vercel para el despliegue
• API de Claude (opcional) para sugerir categorías de comercios desconocidos

Antes de este proyecto, yo no tenía ni idea de qué era Drizzle ORM. Tampoco me hacía falta saberlo de antemano: lo crucial era definir el objetivo y tener criterio para evaluar las propuestas de la IA.

Al pedirle a Claude Code una app de presupuestos para un único hogar, con autenticación y despliegue en Vercel, sugirió este stack. Le pregunté por qué Drizzle frente a Prisma (me detalló rendimiento y tipado) y por qué Supabase Auth en lugar de un sistema propio (seguridad y menor superficie de mantenimiento). Fueron conversaciones técnicas rigurosas guiadas desde la perspectiva de producto.

El modelo mental: un despliegue = un hogar

Family Finances no es un SaaS multiusuario. Cada despliegue corresponde a un hogar independiente: tu base de datos es exclusivamente tuya y tu instancia corre aislada.

Evitamos centralizar datos financieros familiares en servidores compartidos con terceros ni depender de que un servicio externo cambie sus condiciones o cierre.

Es software que controlas tú. Se despliega, se utiliza y, si decides migrar, conservas la base de datos íntegra con todo tu histórico.

Cómo fue el proceso real con Claude Code

El desarrollo no tuvo nada de mágico: fue iterativo, desordenado y a ratos frustrante, como cualquier proyecto real.

• Primera semana (Estructura): Definición del modelo de datos con Claude Code, migraciones con Drizzle y esqueleto de Next.js a partir del contexto del hogar (dos personas, gastos compartidos, presupuestos por categoría).
• Segunda semana (Interfaz): Dashboard, formularios de transacciones y wizard de setup. Aquí el criterio de diseño fue clave: corregir la jerarquía visual (“el balance mensual debe ser lo primero que se ve al abrir la app”) y recortar campos innecesarios en los formularios.
• Tercera semana (Lógica avanzada): Importación de extractos CSV, motor de auto-categorización y visualización de reportes históricos.

La primera versión se quedó en 27 commits. Hoy el repositorio suma 41: cada uno refleja una iteración concreta sobre el producto.

Lo que aprendí sobre seguridad (por las malas)

Al construir rápido con IA, es fácil descuidar la higiene del repositorio si no prestas atención.

En las primeras versiones, la clave anónima de Supabase quedó expuesta en un archivo de configuración. Al pedirle a Claude Code una auditoría explícita de seguridad, identificamos el problema e incorporamos reglas estrictas en el repositorio:

• Ningún archivo .env.local con credenciales reales en Git.
• Ningún estado temporal del CLI de Supabase.
• Cero exportaciones de CSV con transacciones reales.
• Ningún token de servicio en código cliente.

Y no fue la última vez. En septiembre, con la app ya en uso diario, le pedí a Claude Code otra auditoría a fondo y encontró algo más grave: las políticas de seguridad de Supabase permitían que cualquiera que se registrase con la clave pública pudiera leer los datos del hogar a través de la API de datos. La app solo accede a la base de datos desde el servidor, así que la solución fue cerrar esa puerta por completo: RLS en todas las tablas, fuera las políticas permisivas y sin acceso para los roles públicos. De paso aparecieron otros fallos silenciosos: importes guardados como números de coma flotante (ahora son decimales exactos), devoluciones que contaban como ingresos o cargos idénticos en el mismo segundo que se descartaban como duplicados.

El coste real: tiempo y recursos

El desglose real del proyecto:

• Coste directo: 0 €. Supabase y Vercel ofrecen tiers gratuitos suficientes para este volumen, y PostgreSQL corre sobre la capa gratuita de Supabase.
• Tiempo invertido: Unas 3 semanas de trabajo intermitente (tardes y fines de semana), sumando aproximadamente 30-40 horas.
• Referencia de mercado: Desarrollar esta misma solución con un freelance o agencia rondaría habitualmente entre 3.000 € y 8.000 €, además de varias semanas de coordinación.

No se trata de sustituir el trabajo de ingeniería, sino de aprovechar la ventaja que ofrece la IA a perfiles operativos: transformar una necesidad cotidiana en software robusto y funcional sin intermediarios.

Seis meses después: rediseño y una app que aprende

La primera versión funcionaba, pero tenía cara de plantilla. Hoy, 1 de octubre, le he dado la vuelta en una sola sesión con Claude Code:

• Un rediseño completo (“Libreta”): paleta cálida de papel con verde pino, latón y terracota, tipografías Fraunces e Instrument Sans, temas claro y oscuro sin parpadeo y un pequeño kit de componentes compartido por todas las pantallas. Los estados se muestran con icono y texto, nunca solo con color.
• Transacciones como un libro de cuentas: movimientos agrupados por día, selector de categoría en línea y una marca Auto para lo que la app ha categorizado sola.
• Categorización que aprende del histórico: normaliza el nombre del comercio, pondera por importe y usa similitud de texto para reconocer variantes que nunca ha visto (“Farmacia Sant Jordi Alella” es la misma farmacia de siempre). Con confianza alta aplica la categoría al importar; con confianza media la deja como sugerencia en la bandeja de revisión. Si configuras una clave de Anthropic, los comercios totalmente desconocidos se le pueden preguntar a Claude.
• Importaciones más robustas: los cargos devueltos (DEVUELTO en los extractos en español de Revolut) ya no cuentan como gasto, y si Revolut renombra un comercio entre dos exportaciones (“Suma Alella” → “Suma”) el movimiento no se duplica.
• El día 1 ya no es un mes vacío: si el mes actual aún no tiene movimientos, la app abre el último mes con datos y lo avisa.
• Móvil de verdad: sin scroll lateral, filas legibles, campos de 16 px para que iOS no haga zoom y botones visibles sin hover.

Por debajo, el código también ha madurado: validación de todas las entradas de la API con Zod, fechas con tipos reales en la base de datos, rutas en inglés, una batería de tests con Vitest y un pipeline de CI que ejecuta lint, comprobación de tipos, tests y build en cada cambio. Nada de esto se ve, pero es lo que permite seguir iterando sin miedo a romper el presupuesto de casa.

Qué cambiaría si empezara hoy

Con la aplicación en producción durante meses, hay decisiones que enfocaría distinto:

1. Priorizar los reportes sobre el dashboard: A largo plazo, el valor real reside en analizar las tendencias plurianuales, no solo en la foto fija del mes corriente.
2. Parsers multi-banco nativos: El conversor inicial se diseñó para Revolut; adaptarlo a otras entidades después requirió trabajo extra que se podría haber parametrizado antes.
3. Automatizar gastos recurrentes: Alquiler, suscripciones y suministros se repiten idénticos cada mes; registrarlos manualmente resta agilidad.

El README del repositorio incluye una hoja de ruta con estas extensiones (más bancos, reglas automáticas avanzadas y adjuntos de recibos) para quien quiera continuar construyendo sobre esta base.

Criterio humano, ejecución asistida

La IA no sustituye el criterio. En ningún momento Claude Code decidió qué modelo de datos convenía a mi familia, por qué la entrada de gastos debía ser intencionada ni qué nivel de aislamiento requería nuestra información financiera.

Esas decisiones nacen de entender el problema real y tener clara la experiencia que queríamos en casa. La herramienta ejecutó el código; el diseño y la dirección los pusimos nosotros.

Si quieres probar la aplicación o usarla como punto de partida para tus propios proyectos, tienes el código abierto en github.com/pacoforet/family-finances (se abre en una pestaña nueva).