Criar uma App de Orçamento como Desenvolvedor a Solo

A maioria das apps de orçamento trata o dinheiro como um jogo que tens de ganhar.

Pontos por poupar. Sequências por registar. Medalhas por seres responsável com as tuas próprias finanças, como se a vida adulta precisasse de mais uma tabela de classificação.

Percebo porque existe. A gamificação funciona para o envolvimento. Faz com que as pessoas abram a app mais vezes. Cria uma sensação de progresso mesmo quando os números se movem devagar. Para algumas pessoas, é exatamente disso que precisam.

Eu não sou uma dessas pessoas.

O PiggyPulse não nasceu de um desejo de criar uma app de orçamento. Nasceu de uma frustração simples: não conseguia encontrar uma que servisse.

O problema: o ordenado no dia 25

Recebo o ordenado no dia 25 de cada mês. Se o dia 25 calha a um sábado, recebo na sexta. Se for domingo, recebo na segunda. Isto não é incomum nos ciclos de pagamento europeus, mas a maioria das apps de orçamento assume que o dinheiro chega no dia 1.

Os orçamentos baseados no mês não funcionam quando o teu mês começa no dia 25. E todas as apps que experimentei queriam que ou me adaptasse ao calendário ou aceitasse algum período personalizado mal amanhado que parecia uma reflexão tardia.

Essa foi a primeira falha.

A segunda foi a gamificação. Não quero uma pequena animadora digital a julgar os meus hábitos de gastos. Não preciso de uma medalha por não comprar café. Quero ver para onde vai o meu dinheiro sem sentir que estou a ser repreendido ou recompensado por decisões financeiras normais.

Procurei uma app que conseguisse lidar com períodos de orçamento personalizados sem transformar o orçamento numa competição de personalidade. Não encontrei nenhuma.

Então decidi construí-la eu próprio.

Porquê Rust, e não a escolha óbvia

Queria aprender Rust há muito tempo. Não porque estivesse na moda, mas porque o produto que tinha em mente precisava de ser estável e seguro. Uma app de orçamento lida com dados financeiros. Se ia pedir às pessoas que confiassem os seus registos de gastos a algo que construí, queria que a base fosse sólida.

O Rust correspondia a 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 a solo que não se pode 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 conseguia tratar de pedidos e devolver dados. Já sabia que usaria Argon2 para hashing de palavras-passe quando adicionasse autenticação. Isso não foi um palpite. A minha tese de mestrado foi sobre esquemas de hashing de palavras-passe (PHS). Algumas coisas ficam connosco.

A web app funcional mais feia do mundo

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

Sabia o que queria que a app fizesse. Sabia como funcionam as web apps. Mas desenho coisas como engenheiro, e a primeira versão web tinha exatamente o aspeto do que um engenheiro constrói sem um designer na sala.

Funcionava. Tinha a funcionalidade de que precisava. Tinha uma shell de app, menus, tema claro e escuro. Tudo com componentes Mantine. Mas era rudimentar. Tudo estava no sítio certo e nada parecia pertencer ali.

Tudo bem. Estava a construir para mim primeiro. O polimento podia vir depois.

Agentes de IA a desenhar o meu logótipo

A certa altura, percebi que esta coisa estava mesmo a ganhar forma. Tinha uma API funcional, uma web app operacional e uma ideia clara do que queria que fizesse. Foi nesse momento que decidi parar de construir uma ferramenta pessoal e começar a construir um produto a sério.

Essa mudança alterou a forma como trabalhava. Comecei a trazer IA para o processo — não como gerador de código, mas como parceiro de treino.

Discutimos funcionalidades juntos, como dois product managers numa sala. Eu tinha opiniões. A IA tinha sugestões. Ida e volta até a lista de funcionalidades fazer sentido. Depois mudei para modo designer, e a IA tornou-se a minha crítica de design. Percorremos mock-ups no Figma, diferentes versões, diferentes estéticas, até chegarmos a algo que parecia certo.

A app ainda se chamava qualquer coisa como “budgeting-app” e “budgeting-api” nessa altura. O passo seguinte foi um nome e logótipo a sério.

Queria algo leve. Sem gráficos, sem diagramas, sem objetivos na marca. Apenas algo que trouxesse um pouco de calor ao cenário do orçamento. Chegámos a um mealheiro. Simples, reconhecível, ligado a finanças sem parecer corporativo.

Mas a app foi construída à volta de dados. Painéis, tendências, verificações de gastos. Uma verificação do pulso das tuas finanças.

Um mealheiro com uma verificação do pulso.

PiggyPulse escreveu-se sozinho depois disso.

O nome que funcionou por acidente

O nome não foi alcançado através de pesquisa de mercado ou testes A/B. Foi o resultado de uma longa conversa entre mim e a IA sobre o que a app parecia ser. O mealheiro representava leveza. O pulso representava consciência. Junta-os e obténs uma app de orçamento que faz o check-in sem julgar.

Essa continua a ser a ideia central do PiggyPulse. É uma app de orçamento tranquilo. Não está aqui para otimizar a tua vida. Está aqui para te ajudar a reparar no que está a acontecer com o teu dinheiro.

iOS lançado, Android bloqueado por um telemóvel

Com a API e a web app no lugar, apontei para o mobile. Queria apps nativas — iOS e Android.

Nunca tinha criado uma app para iOS ou Android antes. Não fazia ideia do que estava a fazer. Por isso, aprendi os dois fluxos de desenvolvimento com a IA a segurar-me a mão a cada passo. A esta altura, também já tinha migrado a API da v1 para a v2 para facilitar o suporte a múltiplos clientes com um fluxo consistente.

A app iOS chegou à App Store. Foi um marco importante. Um desenvolvedor a solo, um backend em Rust, uma web app em Mantine e uma app iOS de verdade na loja.

A app Android não foi mais além. Não porque não a conseguisse construir. Precisava de um dispositivo Android físico para ativar a minha conta de developer Google Play e simplesmente não tinha um. Esse foi o bloqueio. Um pedaço de hardware entre a app e a Play Store.

Encriptar os dados, traduzir a experiência

A última grande funcionalidade que queria era encriptação em repouso. Se alguém vai armazenar os seus registos financeiros na minha app, esses registos não devem ser legíveis se a base de dados for comprometida.

Essa migração foi complexa. Todo o fluxo teve de mudar para suportar encriptação do lado do cliente mantendo a app funcional. Mais uma vez, os agentes de IA ajudaram a planear e executar.

Depois vieram as traduções. A app estava em inglês, mas queria que chegasse às pessoas nas suas próprias línguas. Falo inglês e português fluentemente, mas as outras línguas — espanhol, francês, neerlandês, alemão — estavam fora da minha capacidade. A IA tratou das traduções. O resultado foi uma app multilingue construída por alguém que só fala duas das línguas que suporta.

Múltiplos agentes, um construtor

Uma coisa que não esperava foi o quanto iria depender de agentes de IA a rever o trabalho uns dos outros.

Um agente escrevia código. Outro revia-o. Iam e vinham até concordarem numa solução. Eu fazia a revisão final antes de fazer merge, mas as primeiras passagens eram tratadas pelos próprios agentes. Parecia ter uma pequena equipa sem a folha de pagamentos.

Vale a pena ser honesto sobre isto: escrevi cada linha de código nas fases iniciais. Cada uma delas. Mas assim que a base ficou sólida e o âmbito cresceu, a IA tornou-se o motor que tornou o desenvolvimento a solo sustentável.

Disponível para qualquer pessoa

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

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

Escolhi open source por três razões.

Primeiro, transparência. Se estou a pedir às pessoas que confiem os seus dados financeiros a esta app, devem poder ver exatamente como funciona. O esquema de encriptação. Os contratos da API. As queries da base de dados. Nada escondido.

Segundo, comunidade. A revisão de segurança e ideias de funcionalidades beneficiam de perspetivas diversas. Open source torna isso possível sem precisar de uma equipa a tempo inteiro.

E terceiro, construir em público mantém-me honesto. Quando sabes que outras pessoas podem ler o teu código, escreves código melhor. Documentas mais. Pensas duas vezes antes de cortar uma esquina.

Está em github.com/leocalm/piggy-pulse. Se quiseres ver uma API em Rust construída com Rocket, o frontend React, como funciona a encriptação em repouso por baixo do capô, ou apenas ler o histórico de commits de um projeto que começou como uma frustração pessoal — está tudo lá.

Nada disto foi uma linha reta

Olhando para trás, o caminho até um PiggyPulse lançado foi desorganizado. Começou com uma frustração pessoal sobre ciclos de ordenado. Passou por uma API em Rust sem autenticação, uma web app que parecia desenhada por um engenheiro, uma fase de design guiada por IA, uma sessão de naming que demorou mais do que construir o primeiro protótipo, um lançamento iOS, um bloqueio Android, uma migração de encriptação e cinco traduções de idiomas.

Nada foi planeado do início ao fim. Cada passo emergiu do anterior.

Essa é a versão honesta de construir um produto sozinho. Não segues um roadmap. Segues o próximo problema interessante. Alguns problemas são técnicos. Alguns são decisões de design. Alguns são simplesmente precisar de um telemóvel que não tens.

Mas o resultado é uma app que faz exatamente o que eu precisava que fizesse. Sem gamificação. Sem julgamento. Apenas um lugar para acompanhares o teu dinheiro ao teu ritmo, no teu próprio horário.

O PiggyPulse existe porque nenhuma das apps existentes servia. E às vezes, quando nada serve, constróis a tua própria.

Isso é suficiente.