🚀 FinançasAI: do “funciona” ao beta — preparando um app financeiro para usuários reais
Estou desenvolvendo o **FinançasAI**, um app de organização financeira pessoal, e nas últimas semanas entrei em uma etapa que considero uma das mais importantes do projeto:
**endurecer o sistema antes de colocar mais usuários reais dentro dele.**
No começo, é fácil pensar:
**usuário → ação → banco → sucesso**
Na prática, existem vários caminhos intermediários:
- banco confirma;
- banco retorna erro;
- banco não confirma a alteração;
- Storage falha;
- signed URL falha;
- usuário repete a ação;
- duas operações acontecem ao mesmo tempo.
E foi justamente nesses caminhos que comecei a encontrar alguns dos problemas mais interessantes.
## 🖼️ Um exemplo: avatar
Um upload de foto parece simples:
**upload → salvar URL → apagar foto antiga**
Mas o que acontece se o upload funcionar e o banco não confirmar a atualização?
Ou se o banco confirmar, mas a signed URL não puder ser criada?
Ou se a remoção da foto antiga falhar?
A solução foi separar responsabilidades:
**persistência ≠ apresentação ≠ limpeza**
Assim:
- o avatar confirmado no banco não é removido por uma falha visual;
- uma limpeza de Storage pode falhar sem quebrar o fluxo principal;
- uma atualização não confirmada não gera falso sucesso;
- falhas de signed URL podem cair para as iniciais;
- operações potencialmente destrutivas usam estratégias **fail-safe**.
## 🧪 E os testes?
Outra mudança importante foi parar de testar apenas:
> “deu certo?”
e começar a testar:
> “o que acontece quando dá errado?”
A suíte já está próxima de **500 testes**, além de:
- TypeScript;
- lint;
- build;
- `git diff --check`;
- testes comportamentais dos fluxos críticos.
O objetivo não é ter um número bonito de testes.
É conseguir responder:
> **“Se essa operação falhar no meio, o estado do usuário continua seguro?”**
## 🔐 Outra coisa que aprendi
Em algumas mutations, usar algo genérico como `Partial<Goal>` pode parecer conveniente.
Mas quando uma operação deveria aceitar somente:
`id`, `current_amount` e `completed`
é melhor deixar o contrato explícito.
E não confiar somente no TypeScript.
A própria mutation também deve construir explicitamente o payload que será enviado ao banco.
Isso protege contra campos extras tanto **em compile time quanto em runtime**.
---
Agora estou chegando em outra etapa do projeto:
## 👥 Colocar o FinançasAI nas mãos de pessoas que não são eu
Esse talvez seja o teste mais difícil até agora.
Eu já conheço:
- onde clicar;
- o que cada tela deveria fazer;
- quais limitações existem;
- quais comportamentos são intencionais.
Um usuário novo não conhece nada disso.
Então o próximo objetivo não é simplesmente conseguir mais cadastros.
É descobrir:
> **“O que acontece quando alguém usa o produto sem conhecer a cabeça de quem o construiu?”**
Estou procurando algumas pessoas para participar desse primeiro beta e dar feedback sincero — principalmente sobre:
- coisas confusas;
- bugs;
- funcionalidades que não fazem sentido;
- dificuldades durante o primeiro uso;
- pontos que poderiam ser mais simples.
Não estou procurando apenas elogios.
Na verdade, prefiro descobrir agora aquilo que pode incomodar um usuário real.
## 🚀 Quer testar o FinançasAI?
O beta está disponível:
👉 **https://chat-financas-ease.vercel.app**
Se você testar, quero muito saber:
- o que ficou confuso;
- o que você melhoraria;
- se encontrou algum bug;
- se o aplicativo realmente ajuda no controle financeiro;
- e se você voltaria a utilizá-lo.
Feedback sincero é muito bem-vindo. 🙏
Se você também está construindo um projeto e já passou pela fase de transformar **“funciona” em “está pronto para usuários reais”**, compartilha sua experiência.
#DIO #Desenvolvimento #React #TypeScript #Supabase #Testes #SoftwareEngineering #FinançasAI #OpenToWork
