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: 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: Estado del mes de un vistazo: categorías en verde, desviaciones y actividad reciente.
• Entrada manual de transacciones: Manual de forma intencionada. Queríamos que registrar un gasto fuese un acto consciente, no invisible.
• Importación de CSV: Soporte para importar extractos de Revolut cuando se acumulan tickets.
• Auto-categorización por reglas: Si el concepto contiene “Mercadona”, lo clasifica automáticamente en Supermercado.
• 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
• Vercel para el despliegue

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.

El repositorio suma 27 commits; 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.

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.

Qué cambiaría si empezara hoy

Con la aplicación en producción durante semanas, 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.