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 vamos a gestionar los gastos comunes. Quién paga qué. Cómo repartimos.
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. Funcionó durante exactamente tres semanas.
El problema no era el Excel en sí. Era todo lo demás. Que si yo me olvidaba de apuntar el supermercado, que si ella no encontraba la pestaña correcta, que si los totales del mes no cuadraban porque alguien borró una fórmula sin querer. Necesitábamos algo mejor, pero las apps de finanzas que probamos o eran demasiado genéricas, o pedían conectar cuentas bancarias (no, gracias), o costaban una suscripción mensual para funcionalidades que no necesitábamos.
Y ahí fue cuando pensé: ¿Y si me lo construyo yo?
De “necesito una app” a “tengo un repositorio en GitHub”
Hace un año, esa frase habría sido un chiste. Yo no soy programador. Soy un perfil de marketing y negocio que ha aprendido a usar la IA como herramienta de construcción. Mi filosofía es la del Director de Orquesta: no necesito saber tocar el violín, el oboe y la percusión. Necesito saber cómo debe sonar la pieza completa.
Mi instrumento principal es Claude Code. Y el proyecto que salió de aquella necesidad doméstica se llama Family Finances: una aplicación web completa, funcional, desplegada en Vercel, con base de datos real en PostgreSQL y autenticación con Supabase.
No es un prototipo. No es un juguete. Es la app que usamos en casa cada día para gestionar nuestro presupuesto.
Y ahora, además, el repositorio ya no está preparado solo para mí. Lo he dejado listo para que otras personas puedan clonarlo, configurarlo y usarlo tal cual, o tomarlo como base para construir su propia versión.
Qué hace exactamente Family Finances
Antes de entrar en cómo la construí, dejadme explicar qué hace. Porque lo importante no es la tecnología, es el problema que resuelve.
- Wizard de configuración inicial: La primera vez que entras, te guía para elegir nombre del hogar, idioma, moneda, zona horaria y tamaño del grupo familiar. Nada de configuraciones crípticas.
- Presupuestos mensuales por categoría: Defines cuánto quieres gastar en supermercado, ocio, transporte… y la app te muestra en tiempo real cuánto llevas gastado vs. presupuestado.
- Dashboard con resumen visual: De un vistazo ves el estado del mes: qué categorías van bien, cuáles se están pasando, y la actividad reciente.
- Entrada manual de transacciones: Sí, manual. A propósito. Quería que el acto de apuntar un gasto fuera consciente, no automático.
- Importación de CSV: Para cuando acumulas recibos, puedes importar los extractos de Revolut (y con algo de trabajo, de otros bancos).
- Auto-categorización por reglas: Le dices “si el concepto contiene ‘Mercadona’, ponlo en Supermercado” y a partir de ahí lo hace solo.
- Reportes mensuales y anuales: Tendencias de gasto a lo largo del tiempo. Esto es lo que un Excel nunca te da bien.
- Soporte bilingüe: Español e inglés, con formateo adaptado al locale.
El stack: decisiones de producto, no de ingeniero
Aquí viene la parte que a mucha gente le sorprende. El stack tecnológico de esta app no es precisamente sencillo:
- 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
Si te digo que yo no sabía qué era Drizzle ORM antes de empezar este proyecto, me creerías. Y es la verdad. Pero no necesitaba saberlo antes. Necesitaba saber qué quería construir y tener el criterio para evaluar si lo que Claude Code me proponía tenía sentido.
Cuando le dije a Claude Code que quería una app de presupuestos para un solo hogar, con autenticación, desplegable en Vercel, me propuso este stack. Yo le pregunté por qué Drizzle y no Prisma. Me explicó las ventajas de tipado y rendimiento. Le pregunté por qué Supabase Auth y no un sistema propio. Me habló de seguridad y mantenimiento. Tuve conversaciones técnicas reales sin ser técnico. Eso es ser Director de Orquesta.
El modelo mental: un despliegue = un hogar
Una decisión de diseño que me parece especialmente interesante es el modelo de producto. Family Finances no es un SaaS multiusuario. Es justo lo contrario: cada despliegue es un hogar. Tu base de datos es solo tuya. Tu instancia es solo tuya.
Esto puede parecer una limitación, pero en realidad es una decisión de producto muy consciente. No quiero que los datos financieros de mi familia estén en una base de datos compartida con miles de desconocidos. No quiero depender de que un servicio externo no cierre o cambie sus precios.
Es software que te pertenece. Lo despliegas, lo usas, y si mañana quieres dejarlo, tienes tu base de datos con todos tus datos.
Si quieres probarlo, ahora puedes clonar el repositorio y seguir un proceso de setup pensado para terceros. Solo necesitas un proyecto en Supabase, configurar las variables de entorno y desplegarlo en Vercel. El README explica los pasos para levantar tu propia instancia o usarlo como starter para otra app similar.
Cómo fue el proceso real con Claude Code
Voy a ser honesto: no fue un proceso limpio de “le dije qué hacer y salió perfecto”. Fue iterativo, desordenado, y a veces frustrante. Como cualquier proyecto real.
La primera semana fue todo estructura. Le pedí a Claude Code que creara el esquema de base de datos, las migraciones con Drizzle, y la estructura básica de Next.js. Le di contexto de negocio: “Somos dos personas, queremos controlar gastos comunes, necesitamos categorías y presupuestos mensuales.”
La segunda semana fue la interfaz. El dashboard, los formularios de transacciones, el wizard de setup. Aquí es donde más tuve que intervenir como Director de Orquesta. Claude Code generaba componentes funcionales, pero yo tenía que decirle cosas como: “No, el resumen mensual tiene que estar arriba del todo, es lo primero que quiero ver al abrir la app” o “El formulario de nueva transacción tiene demasiados campos, simplifica.”
La tercera semana fue la más divertida. Importación de CSV, reglas de auto-categorización, reportes. Son funcionalidades que en un desarrollo tradicional habrían requerido semanas de trabajo de un equipo. Yo las tuve en días, iterando rápidamente con Claude Code.
El repositorio tiene 27 commits. Cada uno cuenta una historia de evolución del producto.
Lo que aprendí sobre seguridad (por las malas)
Una cosa que me gustaría destacar es la seguridad. Cuando trabajas con IA para construir software, es fácil dejarse llevar por la velocidad y olvidarte de las buenas prácticas. Yo cometí ese error al principio.
En las primeras versiones, la clave anónima de Supabase estaba donde no debía. Claude Code me lo señaló cuando le pedí que revisara la higiene del repositorio. El README ahora tiene una sección explícita sobre qué nunca debe commitearse:
- Nada de archivos
.env.localcon credenciales reales - Nada de estados temporales del CLI de Supabase
- Nada de exports de CSV con datos financieros reales
- Nada de tokens de servicio en código del cliente
Si usas Claude Code, o cualquier herramienta de IA, para construir software que maneja datos sensibles, dedica tiempo explícito a pedirle una auditoría de seguridad del repositorio. No des por hecho que lo hace solo.
El coste real: tiempo y dinero
Seamos transparentes. ¿Cuánto me costó todo esto?
En dinero: prácticamente nada. Supabase tiene un plan gratuito generoso. Vercel tiene despliegue gratuito para proyectos personales. Claude Code es parte de mi suscripción habitual. La base de datos PostgreSQL corre en el tier gratuito de Supabase.
En tiempo: unas tres semanas de trabajo intermitente. No a jornada completa, esto lo hacía por las tardes y fines de semana, entre otras cosas. Calculo que invertí unas 30-40 horas en total.
¿Cuánto habría costado con un desarrollador freelance? Siendo conservador, una app con este stack, estas funcionalidades y este nivel de pulido podría estar entre 3.000€ y 8.000€. Y varias semanas más de calendario.
No digo esto para quitarle valor al trabajo de los desarrolladores. Lo digo para ilustrar lo que la IA hace posible para perfiles como el mío: convertir conocimiento de negocio en producto funcional sin intermediarios.
Qué haría diferente si empezara hoy
Con la perspectiva de tener la app funcionando en producción durante varias semanas, hay cosas que cambiaría:
- Empezaría con los reportes, no con el dashboard. Resulta que lo que más valor aporta a largo plazo no es ver el estado del mes actual, es ver las tendencias a lo largo del tiempo.
- Añadiría parsers de CSV para más bancos desde el principio. El actual está optimizado para Revolut, y cuando intenté importar un extracto de otro banco, tuve que pedirle a Claude Code que adaptara el parser. No fue difícil, pero habría sido mejor planificarlo.
- Implementaría transacciones recurrentes desde el día uno. El alquiler, Netflix, el gimnasio… son gastos que se repiten cada mes y apuntarlos manualmente es tedioso.
El propio README del repositorio tiene una sección de extensión que refleja esto: soporte para más bancos, transacciones recurrentes, permisos por miembro del hogar, almacenamiento de recibos…
Y esa parte me parece especialmente valiosa: el proyecto ya está documentado no solo para entender cómo funciona, sino para que otra persona pueda clonarlo, hacer el setup en su entorno y extenderlo sin empezar desde cero.
La reflexión final: el software como extensión del criterio
Hace cinco años, si me hubieras dicho que un tipo de marketing iba a construir y desplegar una aplicación web fullstack con PostgreSQL, TypeScript y autenticación real, me habría reído. Hoy es mi día a día.
Pero quiero dejar algo claro: la IA no sustituyó el criterio. En ningún momento Claude Code tomó decisiones de producto por mí. No decidió que el modelo fuera un hogar por despliegue. No decidió que la entrada de transacciones fuera manual y consciente. No decidió que la seguridad de los datos fuera una prioridad.
Esas fueron decisiones humanas, basadas en entender un problema real, gestionar las finanzas con mi pareja, y tener una visión clara de cómo resolverlo.
La IA fue el instrumento. Yo fui el Director de Orquesta. Y la música que salió es una app que usamos cada día, que es nuestra, y que ahora también puede ser tuya si la clonas o la tomas como base en github.com/pacoforet/family-finances.
Eso, para mí, es el futuro del trabajo.