Todos os projetos

Finanças

no ar

App de finanças pessoais que instala no celular e funciona offline.

Demo com dados fictícios e sem login. Melhor no celular.

Tela Cartões: fatura calculada a partir das compras Tela inicial: saldo projetado, entradas, saídas e orçamento da semana Tela Guardar: objetivos de economia numa linha do tempo
Cartões · Início · Guardar
tipo
Projeto pessoal
stack
React 19 · TypeScript · Firestore · Tailwind 4 · PWA
testes
1.019 com Vitest, preview de deploy a cada pull request

O problema

Eu controlava meu orçamento numa planilha. Ela respondia “quanto eu gastei”, mas não “quanto vou ter”: fatura de cartão que fecha num dia e vence em outro, compra parcelada que come os meses seguintes, dinheiro separado para um objetivo. O Finanças nasceu para substituir essa planilha e hoje é um app web em produção.

O que ele faz

  • Calcula a fatura de cada cartão a partir das compras, com parcelas distribuídas nos meses certos.
  • Projeta o saldo dos próximos 12 meses.
  • Tem um simulador “Posso gastar?” que mostra o efeito de uma compra antes de ela acontecer.
  • Organiza objetivos de economia numa linha do tempo.
  • Instala no celular e funciona offline (PWA).

Decisões

  1. Dinheiro em centavos inteiros

    Todo valor é guardado e calculado como inteiro em centavos. A conversão para reais acontece só na hora de mostrar na tela.

    Por quê: ponto flutuante não representa 0,10 com exatidão, e somar parcelas em float gera centavos fantasmas. Com inteiros, somas são exatas e dividir R$ 100 em 3 parcelas obriga o código a decidir, de propósito, em qual parcela fica o centavo que sobra.

  2. Regras de negócio em funções puras

    Fatura, previsão de saldo e simulador são funções que recebem dados e devolvem resultado. Não sabem que existe React nem Firestore.

    Por quê: as contas são a parte que não pode errar. Assim elas são testadas com Vitest sem simular banco, e a interface pode mudar sem tocar nelas.

  3. Fronteiras entre camadas verificadas no CI

    O projeto é dividido em camadas, e o CI falha se uma camada importar de onde não deve.

    Por quê: arquitetura que depende só de disciplina se desfaz no primeiro atalho. Com a checagem automática, a regra vale até nos dias de pressa.

  4. Mais de 80 decisões registradas em ADRs

    Cada escolha relevante virou um ADR (Architecture Decision Record): o que foi decidido, por quê e o que foi descartado.

    Por quê: quando volto a um trecho meses depois, o motivo está escrito, e não só na minha memória. Esta página, aliás, sai em boa parte deles.

  5. Preview a cada pull request

    Todo pull request gera um deploy de preview separado da produção.

    Por quê: é um app pensado para a tela do celular. Testar no aparelho de verdade antes do merge pega problemas que o navegador do computador esconde.