🚀 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