Crear una app de presupuesto como desarrollador en solitario

La mayoría de apps de presupuesto tratan el dinero como si fuera un juego que tienes que ganar.

Puntos por ahorrar. Rachas por registrar. Insignias por ser responsable con tu propio dinero, como si la vida adulta necesitara otra tabla de clasificación.

Entiendo por qué existe eso. La gamificación funciona para el engagement. Hace que la gente abra la app más a menudo. Crea una sensación de progreso incluso cuando las cifras avanzan despacio. Para algunas personas, eso es exactamente lo que necesitan.

Yo no soy una de esas personas.

PiggyPulse no nació del deseo de crear una app de presupuesto. Nació de una frustración sencilla: no encontraba ninguna que encajara.

El problema: cobro el día 25

Cobro el día 25 de cada mes. Si el 25 cae en sábado, cobro el viernes. Si es domingo, cobro el lunes. No es nada raro en los ciclos de nómina europeos, pero la mayoría de apps de presupuesto asumen que tu dinero llega el día 1.

Los presupuestos mensuales no funcionan cuando tu mes empieza el día 25. Y todas las apps que probé querían que me adaptara al calendario o aceptara un período personalizado chapucero que parecía un parche de última hora.

Esa fue la primera carencia.

La segunda fue la gamificación. No quiero una animadora digital diminuta juzgando mis hábitos de gasto. No necesito una insignia por no comprar café. Quiero ver adónde va mi dinero sin sentir que me regañan o me premian por decisiones financieras normales.

Busqué una app que supiera manejar períodos de presupuesto personalizados sin convertir el presupuesto en un concurso de personalidad. No encontré ninguna.

Así que decidí construirla yo mismo.

Por qué Rust, y no la opción obvia

Llevaba tiempo queriendo aprender Rust. No porque estuviera de moda, sino porque el producto que tenía en mente necesitaba ser estable y seguro. Una app de presupuesto maneja datos financieros. Si iba a pedirle a la gente que confiara sus registros de gastos en algo que yo había construido, quería que los cimientos fueran sólidos.

Rust cumplía ese requisito. Sin recolector de basura. Sin sorpresas en tiempo de ejecución. Seguridad de memoria garantizada en tiempo de compilación. Para un desarrollador en solitario que no puede permitirse perseguir segfaults a las 2 de la mañana, eso es una ventaja considerable.

La primera versión de la API la construí con Rocket. Todavía no tenía autenticación, eso llegó después, pero ya podía manejar peticiones y devolver datos. Ya sabía que usaría Argon2 para el hash de contraseñas cuando añadiera la autenticación. No era una corazonada. Mi tesis de máster fue sobre esquemas de hash de contraseñas (PHS). Hay cosas que no se olvidan.

La web app funcional más fea del mundo

Cuando la API fue mínimamente viable, necesitaba un frontend.

Sabía lo que quería que hiciera la app. Sabía cómo funcionan las web apps. Pero diseño las cosas como ingeniero, y la primera versión web tenía exactamente el aspecto de lo que construye un ingeniero sin un diseñador en la sala.

Funcionaba. Tenía la funcionalidad que necesitaba. Tenía un shell de app, menús, tema claro y oscuro. Todo con componentes de Mantine. Pero era tosca. Todo estaba en su sitio y nada parecía pertenecer a ese sitio.

Estaba bien. Primero lo construía para mí. El pulido podía llegar después.

Agentes de IA diseñando mi logotipo

En algún momento, me di cuenta de que esto se estaba materializando. Tenía una API funcionando, una web app funcional y una idea clara de lo que quería que hiciera. Fue entonces cuando decidí dejar de construir una herramienta personal y empezar a construir un producto real.

Ese cambio transformó mi forma de trabajar. Empecé a incorporar la IA en el proceso — no como generadora de código, sino como compañera de debate.

Discutíamos las funciones juntos, como dos product managers en una sala. Yo tenía opiniones. La IA tenía sugerencias. Íbamos y veníamos hasta que la lista de funciones tenía sentido. Luego pasaba al modo diseñador, y la IA se convertía en mi crítica de diseño. Repasábamos mockups en Figma, versiones distintas, estéticas distintas, hasta que dábamos con algo que sonaba bien.

La app todavía se llamaba algo así como «budgeting-app» y «budgeting-api» en ese momento. Así que el siguiente paso era un nombre y un logotipo de verdad.

Quería algo ligero. Sin gráficos, sin diagramas, sin objetivos en la marca. Solo algo que aportara un poco de calidez al mundillo del presupuesto. Llegamos a una hucha. Sencilla, reconocible, conectada con las finanzas sin resultar corporativa.

Pero la app estaba construida alrededor de datos. Paneles, tendencias, revisión de gastos. Un chequeo de tu salud financiera.

Una hucha con chequeo médico.

PiggyPulse se escribió solo después de eso.

El nombre que funcionó sin querer

El nombre no llegó tras una investigación de mercado ni tests A/B. Fue el resultado de una larga conversación entre la IA y yo sobre qué sensación transmitía la app. La hucha representaba ligereza. El pulso representaba conciencia. Juntándolos obtenías una app de presupuesto que hace seguimiento sin juzgar.

Esa sigue siendo la idea central de PiggyPulse. Es una app de presupuesto tranquilo. No está aquí para optimizarte la vida. Está aquí para ayudarte a notar qué está pasando con tu dinero.

iOS llegó, Android se quedó atrás por un móvil

Con la API y la web app en su sitio, puse la mira en el móvil. Quería apps nativas — iOS y Android.

Nunca había creado una app para iOS ni Android. No tenía ni idea de lo que estaba haciendo. Así que aprendí ambos flujos de desarrollo con la IA guiándome en cada paso. Para entonces, también había migrado la API de v1 a v2 para facilitar el soporte a múltiples clientes con un flujo consistente.

La app iOS llegó a la App Store. Fue un hito importante. Un desarrollador en solitario, un backend en Rust, una web app con Mantine y una app iOS de verdad en la tienda.

La app Android no llegó más lejos. No porque no pudiera construirla. Necesitaba un dispositivo Android físico para activar mi cuenta de desarrollador de Google Play, y simplemente no tenía uno. Ese fue el bloqueo. Un solo dispositivo de hardware entre la app y Play Store.

Cifrar los datos, traducir la experiencia

La última gran funcionalidad que quería era el cifrado en reposo. Si alguien va a guardar sus registros financieros en mi app, esos registros no deberían ser legibles si la base de datos se ve comprometida.

Esa migración fue compleja. Había que cambiar todo el flujo para soportar cifrado del lado del cliente manteniendo la app funcional. Una vez más, los agentes de IA ayudaron a planificarlo y ejecutarlo.

Luego llegaron las traducciones. La app estaba en inglés, pero quería que llegara a la gente en sus propios idiomas. Hablo inglés y portugués con fluidez, pero los otros idiomas — español, francés, neerlandés, alemán — estaban fuera de mi alcance. La IA se encargó de las traducciones. El resultado fue una app multilingüe construida por alguien que solo habla dos de los idiomas que soporta.

Múltiples agentes, un solo constructor

Una cosa que no esperaba era cuánto acabaría confiando en que los agentes de IA revisaran el trabajo de los demás.

Un agente escribía código. Otro lo revisaba. Iban y venían hasta que se ponían de acuerdo en una solución. Yo hacía la revisión final antes de integrar, pero las primeras pasadas las gestionaban los propios agentes. Era como tener un equipo pequeño sin la nómina.

Vale la pena ser sincero al respecto: escribí cada línea de código en las primeras fases. Todas y cada una. Pero una vez que los cimientos fueron sólidos y el alcance creció, la IA se convirtió en el motor que hizo sostenible el desarrollo en solitario.

Disponible para cualquiera

PiggyPulse es código abierto. Todo el proyecto — API, web app, app iOS, documentación — vive en GitHub en github.com/leocalm/piggy-pulse.

No fue una decisión automática. Hay algo incómodo en publicar tu código cuando eres un desarrollador en solitario. Cada commit apresurado, cada abstracción imperfecta, cada decisión que tenía sentido a la 1 de la mañana está ahí fuera para que cualquiera la examine.

Elegí el código abierto por tres razones.

Primero, transparencia. Si le pido a la gente que confíe sus datos financieros a esta app, deberían poder ver exactamente cómo funciona. El esquema de cifrado. Los contratos de la API. Las consultas a la base de datos. Nada oculto.

Segundo, comunidad. Las revisiones de seguridad y las ideas sobre funcionalidades se benefician de perspect diversas. El código abierto lo hace posible sin necesidad de un equipo a tiempo completo.

Y tercero, construir en abierto me mantiene honesto. Cuando sabes que otras personas pueden leer tu código, escribes mejor código. Documentas más. Lo piensas dos veces antes de tomar un atajo.

Está en github.com/leocalm/piggy-pulse. Si quieres ver una API en Rust construida con Rocket, el frontend en React, cómo funciona el cifrado en reposo por debajo, o simplemente leer el historial de commits de un proyecto que empezó como una frustración personal — está todo ahí.

Nada de esto fue una línea recta

Mirando atrás, el camino hasta tener PiggyPulse publicado fue un desastre. Empezó con una frustración personal sobre los ciclos de nómina. Pasó por una API en Rust sin autenticación, una web app que parecía dibujada por un ingeniero, una fase de diseño guiada por IA, una sesión de naming que duró más que construir el primer prototipo, un lanzamiento en iOS, un bloqueo en Android, una migración de cifrado y cinco traducciones a otros idiomas.

Nada de eso estaba planeado de principio a fin. Cada paso surgió del anterior.

Esa es la versión honesta de construir un producto en solitario. No sigues una hoja de ruta. Sigues el siguiente problema interesante. Unos problemas son técnicos. Otros son decisiones de diseño. Y otros son simplemente necesitar un móvil que no tienes.

Pero el resultado es una app que hace exactamente lo que yo necesitaba que hiciera. Sin gamificación. Sin juicios. Solo un sitio donde llevar tu dinero a tu ritmo, en tu propio horario.

PiggyPulse existe porque ninguna de las apps existentes encajaba. Y a veces, cuando nada encaja, construyes la tuya propia.

Eso basta.