Del Google Sheet a mi propia app de gastos en 8 días

Durante mucho tiempo, manejar el dinero fue un problema para mí. Tuve lo que muchos llamarían un happy problem: empecé a tener más ingresos, y nunca controlé lo que entraba, y mucho menos lo que salía, sobre todo en forma de deudas. Me costó resolver ese desequilibrio, y la razón de fondo es incómoda de admitir: nunca tuve educación financiera, ni la más básica.

Lo que me sacó del hueco no fue una app. Fueron tres decisiones de finanzas para niños de 10 años que yo, adulto con salario, nunca había aplicado:

1. Anotar todos los gastos del mes, hasta el más mínimo.
2. Anotar los ingresos.
3. Hacer la resta desde el día 1 y mirar el número de frente: ¿es verde o es rojo?

Después llegó la cuarta pieza, la que más me cambió el juego. Muchos gastos no se pagan el día que llega el salario. ¿Cómo no gastarse esa plata mientras tanto? La respuesta me la dieron los propios bancos con sus bolsillos, cajas y bóvedas: separar el dinero en un espacio donde no lo vea disponible, y si se puede bloquear, mejor. Con el tiempo supe que estaba redescubriendo un clásico de las finanzas personales: el método de los sobres. A mí no solo me ordenó los gastos: es lo que mejor me ha funcionado para ahorrar.

Eso fue hace unos diez años, y desde entonces el sistema fue evolucionando con la tecnología que tuviera a mano: empezó en una hoja de papel cada mes, se convirtió en un cuaderno exclusivo para ello, y cuando por fin logré consistencia se mudó a un Google Sheet llamado “Finance”, con una pestaña de “Torre de control Ingresos / Egresos” por cada mes. El ritual funcionaba: duplicar la pestaña, ajustar los montos, ir marcando lo pagado.

Y desde hacía un año le daba vueltas a convertirlo en una app. Porque el Sheet, con lo práctico que es, se vuelve incómodo para editar “en el momento” desde el teléfono o la tablet (celdas pequeñas, teclado equivocado, un pequeño castigo diario), y sobre todo porque no me avisa nada: una hoja de cálculo no sabe que el arriendo vence mañana.

Este es el segundo capítulo de lo que empecé a contar en la historia de pkmntools: qué pasa cuando un arquitecto de soluciones (no un desarrollador profesional) aplica lo aprendido vibecodeando con agentes de IA. Spoiler: la segunda vez es mucho más rápida.

El intento fallido que enseñó el camino

En mayo lo intenté por primera vez, y lo hice mal. Construí un dashboard en Next.js desplegado en Vercel que leía y escribía el Google Sheet a través de una service account. Quedó grande (casi cinco mil líneas, la página de gastos sola tenía 1.600) y lo abandoné en dos semanas.

La lección tardó meses en aterrizar: envolver la hoja de cálculo no arregla el ritual. El problema no era la interfaz encima del Sheet; era seguir atado al modelo del Sheet. Y había un segundo error de método: empecé por el código (“hazme un dashboard”) en vez de empezar por el diseño.

Ocho días, con la fórmula completa

El 20 de septiembre volví a empezar, esta vez con la fórmula que me dejó pkmntools: primero un spec de diseño con las decisiones escritas y sus porqués, luego un plan de implementación por tareas, y de ahí ejecución con TDD junto a agentes de IA. Ocho días y 109 commits después, la app está en uso diario. Estas fueron las decisiones y sus razones:

Todo en Cloudflare, todo en el free tier. Un solo Worker con Hono sirve el API y los archivos estáticos; los datos viven en Workers KV como un documento JSON por mes, exactamente el modelo mental del Sheet: una pestaña, un documento. La concurrencia es optimista: cada escritura lleva la versión del documento, y si dos pestañas editan a la vez, la segunda recibe un 409 y recarga. Costo de hosting: cero.

Autenticación sin construir autenticación. La app es de un solo usuario (yo), así que no tiene registro, ni contraseñas, ni tabla de usuarios. Cloudflare Access protege el Worker completo con un PIN de un solo uso al correo y una política de exactamente un email permitido. La app es privada por diseño: no hay URL que visitar; este artículo es lo único público que tiene.

Frontend sin framework. Vite + TypeScript y funciones de render sobre estado en memoria. Para una app de un usuario con una grilla y un panel, React era peso muerto. La PWA se instala en la tablet, funciona offline mostrando el último mes leído, y los montos abren teclado numérico.

Restricciones como combustible. El free tier de KV limita los listados a mil por día, así que la app mantiene su propio índice de meses en un documento aparte y nunca lista. El CI corre en Linux porque en Windows el Smart App Control bloquea el runtime local de Workers. Y antes de cada deploy corre un smoke test de Playwright en tres viewports (escritorio, tablet, teléfono) como puerta obligatoria.

El ritual, mejorado en vez de reemplazado

El diseño respeta cómo ya manejaba mis gastos, y solo le quita fricción. Cada gasto está en uno de tres estados (pendiente, separado, pagado) porque así pienso yo la plata: “separado” no es una nota al margen, es un estado de verdad, el método de los sobres hecho software: esa plata ya está en su sobre, solo falta que salga. Y cada gasto lleva su bolsillo, el nombre del sobre donde vive. Deslizar una fila avanza el estado; marcar pagado pone la fecha sola; duplicar mes reproduce el ritual de siempre en un toque; y todo tiene deshacer/rehacer con historial que sobrevive a recargar.

Y lo que el Sheet jamás hizo en diez años: avisar. A las 8 de la mañana llega un aviso push con lo vencido y lo próximo. Lo mejor está en los botones de la propia notificación: “Pagado” marca el gasto con fecha de hoy sin abrir la app, y “Aplazar” lo vuelve a recordar más tarde. La mitad de mi gestión del mes pasa por esos dos botones.

La estrella: el escáner de recibos

La función que más me gusta llegó el día 7. Pago algo, el banco manda su notificación, y yo comparto la captura de pantalla directo a la app (es un share target de Android). Un modelo de visión en Workers AI (Llama 4 Scout) lee el monto, el comercio y la fecha, y la app crea el gasto ya pagado o me sugiere emparejar uno pendiente. Además recuerda cada comercio: la segunda vez que comparto un recibo del mismo lugar, ya sabe a qué concepto, categoría y bolsillo va.

El spike de validación antes de construirlo: 7 de 7 capturas leídas correctamente, entre 1 y 6 segundos cada una, dentro de la cuota gratuita diaria. La imagen del recibo no se guarda nunca: se lee y se descarta.

Lo que me llevo esta vez

1. La fórmula se amortiza. Con pkmntools tardé seis meses en aprender a trabajar así; esta app salió en ocho días. El spec con decisiones escritas es lo que convierte a los agentes de IA en un equipo en vez de una ruleta.
2. El free tier es un gran director de arquitectura. Cada límite (KV, listados, cuota de IA) empujó hacia un diseño más simple, no más pobre.
3. Reemplaza el ritual, no la herramienta. La v1 dejó fuera todo lo que no era la torre de control; el resto del Sheet sigue vivo y no le debo nada.
4. El software personal no necesita escalar. Un usuario, cero hosting, cero mantenimiento planeado. La mejor app es la que se amolda a tu ritual exacto, y esa nadie la vende.

Ahora es open source

Mientras escribía este artículo caí en cuenta de algo: la app ya estaba diseñada para regalarse. Como cada instancia es de un solo usuario, cualquiera puede desplegar la suya en su propia cuenta de Cloudflare: sus datos en su KV, su propio Access, su propio Worker. Nadie ve nada de nadie.

Así que la liberé. El código está en GitHub como arroyave-expenses-control, con licencia MIT y las instrucciones para tener tu propia torre de control en unos 15 minutos, gratis. (El escáner de recibos viene afinado para bancos colombianos (Bancolombia, Nequi, Nu), pero el prompt es tuyo para adaptarlo.)

¿Un Sheet tuyo merece este destino? Mi consejo después de dos intentos: no empieces por el código. Escribe primero qué decisiones ya tomaste sin darte cuenta: ahí está el spec.