Construindo um App de Orçamento como Desenvolvedor Solo

A maioria dos apps de orçamento trata dinheiro como se fosse um jogo que você precisa vencer.

Pontos por economizar. Sequências por registrar. Medalhas por ser responsável com sua própria grana, como se a vida adulta precisasse de mais um placar.

Eu entendo por que isso existe. Gamificação funciona para engajamento. Faz as pessoas abrirem o app com mais frequência. Cria uma sensação de progresso mesmo quando os números estão andando devagar. Para algumas pessoas, é exatamente do que elas precisam.

Eu não sou uma dessas pessoas.

O PiggyPulse não nasceu de uma vontade de construir um app de orçamento. Ele nasceu de uma frustração simples: eu não conseguia encontrar um que servisse.

O problema: pagamento dia 25

Eu recebo no dia 25 de todo mês. Se o dia 25 cai num sábado, recebo na sexta. Se é num domingo, recebo na segunda. Isso não é incomum em ciclos de pagamento europeus, mas a maioria dos apps de orçamento assume que seu dinheiro chega no dia 1.

Orçamentos baseados em mês não funcionam quando seu mês começa no dia 25. E todo app que eu tentei queria que eu ou me adaptasse ao calendário ou aceitasse algum período customizado mal resolvido que parecia um improviso de última hora.

Essa foi a primeira lacuna.

A segunda foi a gamificação. Eu não quero um mini animador digital julgan do meus hábitos de consumo. Eu não preciso de uma medalha por não ter comprado café. Eu quero ver para onde meu dinheiro vai sem sentir que estou sendo repreendido ou recompensado por decisões financeiras normais.

Procurei um app que pudesse lidar com períodos de orçamento customizados sem transformar orçamento numa competição de personalidade. Não encontrei nenhum.

Então decidi construir o meu.

Por que Rust, e não a escolha óbvia

Eu queria aprender Rust há muito tempo. Não porque era modinha, mas porque o produto que eu tinha em mente precisava ser estável e seguro. Um app de orçamento lida com dados financeiros. Se eu ia pedir para as pessoas confiarem seus registros financeiros a algo que eu construí, queria que a base fosse sólida.

Rust atendia esse requisito. Sem garbage collector. Sem surpresas em tempo de execução. Segurança de memória garantida em tempo de compilação. Para um desenvolvedor solo que não pode se dar ao luxo de caçar segfaults às 2 da manhã, isso é uma vantagem significativa.

A primeira versão da API foi construída com Rocket. Ainda não tinha autenticação — isso veio depois — mas já conseguia processar requisições e retornar dados. Eu já sabia que usaria Argon2 para hash de senhas assim que adicionasse autenticação. Isso não foi um chute. Minha dissertação de mestrado foi sobre esquemas de hash de senhas (PHS). Algumas coisas ficam com você.

O web app funcional mais feio do mundo

Assim que a API ficou minimamente viável, eu precisei de um frontend.

Eu sabia o que queria que o app fizesse. Eu sabia como web apps funcionam. Mas eu projeto coisas como engenheiro, e a primeira versão web parecia exatamente o que um engenheiro constrói sem um designer na sala.

Funcionava. Tinha a funcionalidade que eu precisava. Tinha um app shell, menus, temas claro e escuro. Tudo usando componentes Mantine. Mas era rudimentar. Tudo estava no lugar certo e nada parecia que pertencia ali.

Tudo bem. Eu estava construindo para mim primeiro. Polimento podia vir depois.

Agentes de IA desenhando meu logo

Em algum momento, percebi que essa coisa estava realmente se encaminhando. Eu tinha uma API funcional, um web app operacional e uma ideia clara do que queria que ele fizesse. Foi nesse momento que decidi parar de construir uma ferramenta pessoal e começar a construir um produto de verdade.

Essa mudança transformou meu jeito de trabalhar. Comecei a trazer IA para o processo — não como geradora de código, mas como uma parceira de debate.

Discutíamos funcionalidades juntos, como dois product managers numa sala. Eu tinha opiniões. A IA tinha sugestões. Íamos e voltávamos até a lista de funcionalidades fazer sentido. Aí eu virava o designer, e a IA virava minha crítica de design. Passávamos por mockups no Figma, versões diferentes, estéticas diferentes, até chegar em algo que parecia certo.

O app ainda se chamava algo como “budgeting-app” e “budgeting-api” nessa época. Então o próximo passo era um nome e um logo de verdade.

Eu queria algo leve. Nada de gráficos, nada de metas na identidade visual. Só algo que trouxesse um pouco de calor ao cenário de orçamento. Chegamos num cofrinho. Simples, reconhecível, conectado a finanças sem parecer corporativo.

Mas o app era construído em torno de dados. Painéis, tendências, checagens de gastos. Uma checagem de pulso das suas finanças.

Um cofrinho com checagem de pulso.

PiggyPulse se escreveu sozinho depois disso.

O nome que funcionou sem querer

O nome não foi alcançado através de pesquisa de mercado ou teste A/B. Foi o resultado de uma longa conversa entre eu e a IA sobre qual era a sensação do app. O cofrinho representava leveza. O pulso representava consciência. Junte os dois e você tem um app de orçamento que faz check-in sem julgar.

Essa ainda é a ideia central do PiggyPulse. É um app de orçamento calmo. Ele não está aqui para otimizar sua vida. Ele está aqui para ajudar você a perceber o que está acontecendo com seu dinheiro.

iOS na loja, Android barrado por um telefone

Com a API e o web app prontos, foquei no mobile. Eu queria apps nativos — iOS e Android.

Eu nunca tinha construído um app iOS ou Android antes. Não fazia ideia do que estava fazendo. Então aprendi os dois fluxos de desenvolvimento com a IA segurando minha mão em cada passo. Nessa altura, eu também tinha migrado a API da v1 para a v2 para facilitar o suporte a múltiplos clientes com um fluxo consistente.

O app iOS chegou à App Store. Esse foi um marco importante. Um desenvolvedor solo, um backend em Rust, um web app com Mantine e um app iOS de verdade na loja.

O app Android não foi adiante. Não porque eu não conseguisse construí-lo. Eu precisei de um dispositivo Android físico para ativar minha conta de desenvolvedor no Google Play, e simplesmente não tinha um. Essa foi a barreira. Um pedaço de hardware entre o app e a Play Store.

Criptografando os dados, traduzindo a experiência

A última grande funcionalidade que eu queria era criptografia em repouso. Se alguém vai armazenar seus registros financeiros no meu app, esses registros não deveriam ser legíveis se o banco de dados for comprometido.

Essa migração foi complexa. O fluxo inteiro teve que mudar para suportar criptografia no lado do cliente enquanto mantinha o app funcional. Mais uma vez, agentes de IA ajudaram a planejar e executar.

Depois vieram as traduções. O app estava em inglês, mas eu queria que alcançasse pessoas em seus próprios idiomas. Eu sou fluente em inglês e português, mas os outros idiomas — espanhol, francês, holandês, alemão — estavam fora da minha capacidade. A IA cuidou das traduções. O resultado foi um app multilíngue construído por alguém que só fala dois dos idiomas que ele suporta.

Múltiplos agentes, um construtor

Uma coisa que eu não esperava era o quanto eu dependeria de agentes de IA revisando o trabalho uns dos outros.

Um agente escrevia código. Outro revisava. Eles iam e voltavam até chegarem a um acordo sobre a solução. Eu fazia a revisão final antes de mesclar, mas as primeiras passagens eram feitas pelos próprios agentes. Parecia ter um time pequeno sem a folha de pagamento.

Vale ser honesto sobre isso: eu escrevi cada linha de código nos estágios iniciais. Cada uma delas. Mas assim que a base ficou sólida e o escopo cresceu, a IA se tornou o motor que tornou o desenvolvimento solo sustentável.

Disponível para qualquer um

O PiggyPulse é open source. O projeto inteiro — API, web app, app iOS, documentação — está no GitHub em github.com/leocalm/piggy-pulse.

Isso não foi uma escolha automática. Há algo desconfortável em publicar seu código quando você é um desenvolvedor solo. Cada commit apressado, cada abstração imperfeita, cada decisão que fez sentido às 1 da manhã está lá para qualquer um inspecionar.

Escolhi open source por três motivos.

Primeiro, transparência. Se estou pedindo para as pessoas confiarem seus dados financeiros a este app, elas deveriam poder ver exatamente como ele funciona. O esquema de criptografia. Os contratos da API. As consultas ao banco de dados. Nada escondido.

Segundo, comunidade. Revisão de segurança e ideias de funcionalidades se beneficiam de perspectivas diversas. Open source torna isso possível sem precisar de um time em tempo integral.

E terceiro, construir em público me mantém honesto. Quando você sabe que outras pessoas podem ler seu código, você escreve código melhor. Você documenta mais. Você pensa duas vezes antes de cortar um atalho.

É github.com/leocalm/piggy-pulse. Se você quiser ver uma API em Rust construída com Rocket, o frontend React, como a criptografia em repouso funciona por baixo dos panos, ou só ler o histórico de commits de um projeto que começou como uma frustração pessoal — está tudo lá.

Nada disso foi uma linha reta

Olhando para trás, o caminho até um PiggyPulse funcionando foi bagunçado. Começou com uma frustração pessoal sobre ciclos de pagamento. Passou por uma API em Rust sem autenticação, um web app que parecia desenhado por um engenheiro, uma fase de design guiada por IA, uma sessão de nomeação que durou mais que construir o primeiro protótipo, um lançamento no iOS, uma barreira no Android, uma migração de criptografia e traduções para cinco idiomas.

Nada disso foi planejado do início ao fim. Cada passo surgiu do anterior.

Essa é a versão honesta de construir um produto sozinho. Você não segue um roadmap. Você segue o próximo problema interessante. Alguns problemas são técnicos. Alguns são decisões de design. Alguns são só precisar de um telefone que você não tem.

Mas o resultado é um app que faz exatamente o que eu precisava que ele fizesse. Sem gamificação. Sem julgamento. Apenas um lugar para acompanhar seu dinheiro no seu ritmo, na sua agenda.

O PiggyPulse existe porque nenhum dos apps existentes servia. E às vezes, quando nada serve, você constrói o seu.

Isso basta.