Meu Papel
Atuei como Product Designer & Design Engineer, orquestrando o desenvolvimento da Purso através de um workflow AI-First iniciado no design.
Minha responsabilidade foi traduzir a visão de produto em interfaces de alta fidelidade e sistemas de componentes e Design System com Variables e Tokens no Figma, estabelecendo toda a base visual e lógica de interação antes da fase de código.
A partir desses layouts, utilizei o IDE Antigravity para converter o design em lógica funcional e componentes React.
- Pilares: AI-Driven Design, Design Engineering, UI UX, APP Design, Vibe Coding.
- Workflow: Figma (Prototipagem) → Antigravity (Orquestração técnica).
- Modelos: Google Gemini 3 e Claude Opus 4.6
- Infra: Vercel / Supabase / GitHub.
Fevereiro – Maio 2026
Visão Geral do Produto
O embrião da Purso surgiu após eu participar de um workshop do Lucas Marte focado na criação de um Dashboard Financeiro simples para desktop com uso de Antigravity.
Porém, ao observar como os aplicativos tradicionais do mercado falham em engajar o público jovem por serem esteticamente frios e burocráticos, resolvi pegar a base do conhecimento, adotar parte da estrutura adquirida e aplicá-la adaptando em uma solução melhorada e reformada, com camadas muito mais profundas de pesquisa e iteração, complementando o processo de UX de fato, além de priorizar o mobile invés do desktop.
Assim nasceu a Purso: uma plataforma onde o usuário gerencia suas finanças através de ‘ciclos inteligentes’, transformando dados transacionais crus em uma narrativa clara de evolução pessoal.
Resultados e Impacto Real
A otimização do fluxo de transações e a implementação do design orientado por dados geraram métricas reais:
de conversão no fluxo
ante 37% na versão anterior melhora de 53 pontos percentuais após iteração de design
no drop-off do fluxo de transação
Melhora na taxa de abandono do fluxo de 50% para 10% após criação inline de categorias e contas
transações finalizadas no período
user_events) App funcional disponível para teste no frame abaixo.
1. O Problema
Hoje, maioria dos brasileiros estão endividados. Muitas pessoas que conhecemos tem uma dificuldade imensa em administrar sua renda, e não é por falta de apps de gestão de finanças.
Na verdade, o mercado hoje está saturado com essas ferramentas.
Uma simples busca no Google já retorna inúmeras soluções de gestão financeira, e a cada dia que passa mais Product Builders, Programadores e Designers criam novas soluções, visto que é uma aplicação relativamente simples de ser criada, e agora com LLMS e produção agêntica de I.A, materializar essas ideias se torna mais acessível a cada dia.
Então a pergunta, por que, mesmo com tantas soluções de Gestão Financeira disponíveis,
porque o Brasileiro (GEN Z) ainda está endividado?
Hipóteses:
Desalinhamento comportamental.
Saturação de aplicativos financeiros tradicionais que falham em engajar a Geração Z devido à complexidade e estética burocrática, e repetição / pouca variação.
Esforço cognitivo como o principal inimigo da retenção.
Após levantadas as hipóteses, parti para a fase de pesquisa.
O mercado de finanças não tem um problema de funcionalidade, tem um problema de personalidade.
Outros responderam com estética. A Purso responde com arquitetura de hábito.
Apps como Cleo e Nubank já perceberam isso e avançaram na direção certa.
A Purso parte desse diagnóstico e vai um nível abaixo: se o problema é comportamental, a solução não é visual, é arquitetural. Cada decisão de fluxo deve tomada para reduzir o custo cognitivo do registro no momento exato em que o hábito se forma ou se perde.
2. Discovery & Research
Antes de entender direto com o público suas necessidades e dores com relação ao mercado de Apps de finanças, busquei dados quantitativos que sustentassem minha afirmação de que maioria dos brasileiros que conhecemos estão endividados.
E basta uma simples pesquisa para levantar dados suficientes para comprovar essa afirmação.
de brasileiros negativados, o que representa 44% da população adulta. É um recorde histórico, com crescimento de 10% em relação a 2024.
Cada negativado deve, em média, para 2,2 empresas credoras. Quase 1 em cada 3 tem dívidas de até R$ 500. São valores pequenos, mas que acabam travando o orçamento.
Crescimento de +49% nas renegociações de dívidas em 2025.
dívidas de jan a jul de 2025
inadimplentes (era 9,9%)
educação financeira ativamente
Mesmo sendo o grupo menos inadimplente por volume, a Gen Z é o segmento de crescimento mais acelerado e também o que mais busca soluções.
no número total de inadimplentes na última década. Em fev de 2026, o país atingiu 81,7 milhões de pessoas com contas em atraso.
voltam a se endividar
O problema não é pontual, mas sim comportamental. Ferramentas que não criam hábitos não conseguem resolver esse ciclo.
O Brasil não tem falta de apps financeiros.
Tem 73 milhões de pessoas que não conseguem criar o hábito de usá-los.
A inadimplência recorde, combinada com a aceleração da Gen Z nas renegociações e a alta taxa de reincidência, confirma a hipótese central da Purso: o inimigo da saúde financeira não é a falta de informação, mas sim o atrito cognitivo no momento de criar o hábito.
Então, de acordo com minha pesquisa, é possível aferir que existe um número massivo de potenciais usuários que se beneficiariam de utilizar uma solução financeira para resolver suas finanças e se organizar.
Mas era preciso entender, o que faz o usuário brasileiro, sobretudo o usuário Gen Z, não utilizar os outros Apps do Mercado?
Usabilidade? Falta de identidade? Falta de funções utéis que conversem com o estilo de vida? Tudo isso foi pensado.
Conduzi então uma rodada de pesquisa qualitativa direta com usuários Gen Z.
Participaram de uma triagem de formulário, cerca de 17 pessoas Gen Z.
Responderam ao formulário, pessoas de gêneros variados, de 19 a 28 anos, universitários, que trabalham full time ou possuem estágio além da vida acadêmica.
Moradores de Belo Horizonte e Região Metropolitana, foram recrutadas através de link do Google Forms e mensagens diretas / e-mail.
Perfil selecionado por representar o núcleo da Gen Z economicamente ativa, com renda própria mas sem histórico consolidado de gestão financeira.
O fato de 12 em 17 pessoas sofrerem no bar é o "gancho" perfeito para uma funcionalidade de divisão de contas.
Além das perguntas de multípla escolha, deixei uma pergunta chave com um campo livre pro entrevistado digitar.
”Se você pudesse inventar o app de finanças dos sonhos (ou mudar algo nos que já existem), como ele seria?”
13 entrevistados responderam. Dentre as repostas, tive algumas interessantes:
"Queria que mostrasse com mais clareza as informações de forma mais granular e segmentada, gráficos e visualidade. E até projeções. Alguns bancos são muito limitados, não da pra ver tudo diretamente, tenho q fazer os cálculos todos por fora."
"Mais fácil de mexer é que pudesse ser personalizado (não gosto de app com mt coisa e mt informação na mesma tela)."
"Mostrar no que está gastando muito e como pode economizar."
"Gostaria de algo intuitivo, fácil de mexer pq sou uma pessoa prática. Quando algo é muito complicado, eu perco a paciência."
"Uso os cofrinhos do picpay pra separar o dinheiro pra cada tipo de gasto, mas é um saco pq ele fica 'bloqueado' e ai toda vez tenho que entrar e resgatar do cofrinho pra usar. Tem vezes que acabo usando o credito por ser mais rapido (péssimo, gasto mais que devia).
Queria que eu pudesse separar quanto dinheiro tenho pra cada gasto direto no banco mesmo, e quando for pagar algo gasta dessa categoria e me avisa qto ainda tenho (tipo tem no app do flash)"
Síntese
Padrão dominante nas respostas abertas: excesso de campos, falta de personalização e complexidade que gera abandono antes de o hábito se formar.
Nenhum usuário citou falta de funcionalidade. Todos citaram falta de praticidade.
Registrar transações e dividir contas com zero fricção no momento em que acontecem.
Sentir progresso real, não culpa, e que o app trabalha a favor do meu estilo de vida.
O inimigo da saúde financeira não é falta de informação, mas sim o atrito cognitivo no momento em que o hábito se forma ou se perde.
Com base na última resposta, entendi duas dores, e obtive duas oportunidades de atuação:
1. Possibilidade de separar gastos por categoria.
2. Limite do Cartão de crédito sempre visível e fácil acesso.
Benchmarking
Fechando a fase de Discovery, afim de entender os fluxos e padrões já consolidados do mercado e da concorrência, fiz uma pesquisa breve nas telas de outros Apps de finanças como Organnize e Mobills.
Os apps de finança mais utilizados no Brasil num geral, usam cores escuras (preto, cinza escuro, roxo escuro, verde escuro) em seus apps.
Pode ser um dos fatores que causam a idéia de ''mesmisse'' ''tudo igual''
Com base nos dados coletados, priorizei o que realmente importa primeiro.
A pesquisa apontou um padrão claro: o maior inimigo da retenção não é a falta de funcionalidades, é o atrito cognitivo no momento do registro.
Usuários abandonam o hábito financeiro quando o esforço de registrar uma transação é maior do que o benefício percebido imediatamente.
Com isso, defini o núcleo inegociável do MVP: o fluxo de registro de receitas e despesas precisava ser rápido, sem fricção e visualmente recompensador. Em torno disso, adicionei as camadas de visibilidade que o usuário mais pediu, extrato geral, edição e remoção de entradas e o controle de cartões de crédito, citado como ponto cego nos apps concorrentes.
Objetivos pessoais entraram como o segundo pilar: a pesquisa mostrou que usuários Gen Z não poupam por disciplina, poupam por motivação.Ter uma meta visível transforma o comportamento de registrar de obrigação em progresso.
Features externas como calculadora de rolê, scan de nota fiscal e gamificação, foram conscientemente adiadas. Não por falta de valor, mas porque lançar com tudo seria a receita para entregar nada direito. Essas funcionalidades existem no roadmap e são validadas pela pesquisa, mas só fazem sentido sobre uma base sólida de uso diário.
- Registro de receitas e despesas
- Extrato geral com edição e remoção
- Inclusão e acompanhamento de cartões
- Categorias personalizadas de gasto
- Objetivos pessoais de poupança
- Calculadora de rolê
- Scan de nota fiscal
- Gamificação e recompensas
- Inteligência preditiva de gastos
3. Estratégia e Conceitualização
Após a fase de pesquisas, parti para a conceitualização inicial.
A ideia era criar um fluxo básico de usuário para entender a jornada que seria feita dentro do APP.
Nessa fase inicial, inclui o absoluto essencial, mas também trouxe as idéias que viriam em outro momento de implementação.
Apesar do meu foco nesse momento ser no fluxo básico de Receitas e Despesas, Registros e Balanço geral na conta, Optei por já incluir aqui no fluxo tais funcionalidades não essenciais para manter em vista no roadmap.
A segunda etapa da conceitualização, envolveu criar os wireframes de baixa fidelidade, para entender a disposição dos elementos básicos e como as telas conversariam com o fluxo básico dentro dos estipulados anteriormente. (Home – Nova Transação – Registro)
O Purso tem rosto.
Com o fluxo básico definido em baixa fidelidade e testado, fui em direção ao Design System, definir cores, fontes, espaçamentos, tokens, tudo isso é essencial no produto.
Um elemento que foi pensado foi a criação de um mascote e um nome para diferenciar da concorrência com nomes relacionados a dinheiro, cash, finance e etc.
Purso: Purse (bolsa) + Porco – Cria um nome curto, original, e memorável.
O passo lógico seria definir tal mascote para entender a comunicação e identidade do produto, para então, seguir com a parte sistemática.
A maioria dos apps financeiros comunica seriedade através de frieza: ícones genéricos, paletas corporativas, zero personalidade. O Purso foi construído sobre uma premissa diferente: controle financeiro não precisa ser intimidador para ser eficaz.
O porquinho nasceu dessa decisão.
Criado inicialmente com auxílio de IA generativa (Nano Banana) e depois refinado e vetorizado do zero no ilustrator, ele não é um ícone decorativo, é a voz do produto.
A escolha de um mascote em vez de ilustrações genéricas foi deliberada.
Mascotes criam consistência emocional, o usuário reconhece o personagem antes de ler o texto, e isso reduz a carga cognitiva nos momentos de maior atrito.
É o mesmo princípio que faz o Duo do Duolingo ser mais eficaz do que uma notificação de texto: o rosto humaniza a cobrança.
O traço foi intencionalmente mantido simples e monocromático. Qualquer complexidade visual no mascote competiria com os dados financeiros, que são o conteúdo real do produto.
O verde-lima da paleta aparece no mascote apenas como elemento de destaque em momentos de celebração, reforçando a associação da cor com progresso e conquista.
Minimalista, expressivo e construído em preto e branco para não competir com a paleta funcional do app, ele aparece nos momentos em que o usuário mais precisa de contexto emocional: onboarding, estados vazios, confirmações de sucesso e erros.
Funcionalidades como gamificação e conquistas estão no roadmap e foram concebidas com o personagem como eixo central, mas a decisão de criar o mascote antes de implementar essas features foi estratégica: identidade de produto não se constrói depois, ela na verdade, fundamenta tudo que vem depois.
Governança Antes do Código - As Regras que Ninguém Vê, Mas Todo Resultado Reflete
Antes de qualquer prompt, antes de qualquer componente, duas decisões estruturais foram tomadas.
O banco de dados foi desenhado antes do código, não como consequência dele.
A estrutura reflete decisões de produto reais: Account unifica contas bancárias e cartões de crédito num único modelo porque o usuário não pensa em tipos de conta, pensa em dinheiro. FamilyMember existe como entidade separada porque a Purso foi concebida para núcleos familiares, não só indivíduos. RecurringTransaction opera como template, gera transações reais sem duplicar lógica.
A tabela user_events foi a primeira a ser projetada. Produto que não se observa não evolui, isso precisava estar na fundação, não ser adicionado depois.
As Rules como contrato de desenvolvimento
Um dos maiores riscos do desenvolvimento assistido por IA é a deriva silenciosa: a cada prompt, o modelo toma pequenas decisões visuais e técnicas por conta própria. Acumuladas, essas decisões destroem a consistência do sistema.
A solução foi criar um conjunto de rules que funcionam como contrato, não sugestões, regras que o modelo é instruído a seguir antes de escrever qualquer código:
- Hierarquia obrigatória de tokens: semântico → primitivo → conversão inteligente. Valor hardcoded é erro, não opção.
- Layout 100% fluido. Largura fixa em container de página é proibida.
- Mobile-first não negociável. Breakpoints evoluem o layout, nunca o recriam.
- Figma via MCP como fonte de verdade. O frame do Figma é wrapper fluido, nunca container fixo.
O resultado prático: consistência sistêmica em escala, com velocidade de produção que não acumula débito visual.
Governar o processo de IA é tão importante quanto governar o design. Rules mal definidas produzem código que parece certo e quebra silenciosamente.
Design System
O Design System da Purso foi construído com uma premissa clara: cada decisão visual precisa ter um motivo funcional, não apenas estético.
Cor
O verde-lima foi escolhido como cor primária por duas razões simultâneas. A primeira é comportamental: verde é universalmente associado a dinheiro, progresso e aprovação, o que reduz o tempo de interpretação do usuário em ações de confirmação e destaque.
A segunda é de posicionamento: enquanto o benchmarking revelou que os principais apps financeiros do mercado utilizam fundos escuros (preto, roxo escuro, verde escuro), a Purso adota fundos claros com o verde-lima como acento. Isso cria contraste imediato na memória visual do usuário e reforça a personalidade descontraída do produto.
O uso do verde-lima apontado com baixa taxa pelo validador ocorre em contextos puramente estéticos (ex: preenchimento de gráficos) sobre fundos claros .
As informações portadoras de dados atreladas aos gráficos estão sempre legíveis em tons neutros e contrastantes .
Totalmente aprovado. Combina o fundo escuro com tipografia clara , alcançando taxas de leitura imersivas e perfeitas.
Contraste altíssimo no texto primário escuro sobre fundos brancos , focando a atenção na navegação.
A arquitetura visual é sólida e funcional, priorizando a acessibilidade dos dados sem perder a identidade estética moderna.
A paleta foi organizada em variáveis de cor dentro do Figma, não como valores soltos aplicados manualmente tela a tela, mas como um sistema centralizado onde cada cor tem nome, escala e papel definido.
A decisão de trabalhar com variáveis primitivas em vez de tokens semânticos foi intencional para o estágio do projeto: num MVP onde velocidade de execução é crítica, uma camada semântica adiciona overhead de manutenção que só se justifica quando o time escala.
O sistema foi construído para ser evolutivo, as variáveis primitivas estão estruturadas de forma que a camada semântica pode ser adicionada sem refatoração quando o produto crescer.
Tipografia e espaçamento
A escala tipográfica e os espaçamentos foram definidos antes das telas, não derivados delas. Isso inverte o processo comum onde o designer ajusta o espaçamento caso a caso e cria inconsistências silenciosas ao longo do produto.
Com tokens de espaçamento fixos, cada componente respira da mesma forma em qualquer contexto.
Componentes
A biblioteca de componentes da Purso foi construída com reusabilidade como critério principal, cada elemento foi desenhado para funcionar de forma independente e compor telas sem precisar de ajuste manual a cada uso.
Navegação & Inputs cobrem os dois pontos de maior fricção no fluxo de registro: encontrar e classificar.
O campo de busca foi componentizado em dois estados: vazio e ativo, para garantir que o feedback visual de interação fosse consistente em qualquer tela onde aparecesse.
O Dropdown segue a mesma lógica, com estado fechado e expandido documentados como variantes do mesmo componente, eliminando decisões ad-hoc de quem implementa.
Os Cards são os blocos mais densos informativamente do sistema.
O Card de categoria centraliza donut chart, nome e valor num único elemento compacto, tudo que o usuário precisa para entender um centro de custo em menos de um segundo de leitura.
O Card de cartão traz nome do banco com logo real, saldo e data de vencimento com hierarquia tipográfica clara entre dado principal e dado secundário. O componente de check de confirmação fecha o grupo como feedback visual de ação concluída.
A Sidebar foi componentizada em dois estados funcionais: expandida com logo, label de navegação e avatar do usuário, e colapsada com ícones apenas, garantindo que a transição entre os dois modos não quebre nenhum elemento interno.
O verde-lima aparece aqui como único indicador de item ativo, reforçando a associação da cor com estado de seleção em todo o sistema.
O Seletor de Data é um dos componentes de maior complexidade do sistema. Resolve dois problemas simultâneos: seleção de período para filtragem do extrato e visualização de vencimentos futuros via agenda integrada.
O dia atual é destacado em verde-lima, datas com vencimento aparecem em vermelho como alerta passivo, e a lista abaixo do calendário traduz os eventos do mês em linguagem linear, reduzindo a carga cognitiva de interpretar um calendário inteiro.
Os Botões foram documentados em duas famílias, primário em preto e secundário com borda, cada uma com três variações de ícone: leading icon, trailing icon e sem ícone.
Seis variantes no total, cobrindo todos os contextos de ação do produto sem criar novos botões por fora do sistema.
Da teoria à implementação — Figma MCP
O passo que transforma um design system de documento em ferramenta real foi a integração com o Figma via MCP no Antigravity.
Após estruturar todas as variáveis e tokens semânticos no Figma, configurei uma rule específica para que o modelo analisasse o sistema inteiro, paleta, tipografia, espaçamentos, estados de componente, e só criasse ou adaptasse telas respeitando essas definições.
Na prática, isso eliminou a deriva visual que costuma acontecer em projetos de desenvolvimento assistido por IA: sem a rule, modelos tendem a tomar decisões visuais por conta própria a cada prompt. Com ela, o design system passou a funcionar como contrato, o modelo executa dentro das regras, não ao redor delas.
O resultado é consistência sistêmica em escala, com velocidade de produção que não sacrifica a coerência visual.
4 - Alta Fidelidade: Materializando Comportamento em Pixels
A transição dos wireframes para a Alta Fidelidade teve um norte inegociável: o Purso não poderia ter a estética fria e burocrática de um extrato bancário.
Nesta fase, o foco era traduzir os wireframes iniciais baseados nas dores descobertas na pesquisa (ansiedade financeira e aversão a planilhas) em uma interface de baixíssimo esforço cognitivo.
Decidi criar e estruturar o fluxo principal de inserção de nova transação/despesa e de acrescentar conta como o objetivo dessa etapa.
Fluxo principal: Novas Transações / Receita / Cartões / Conta
5 — O Produto em Produção - Do Figma ao Usuário Real
O design system estava pronto. Os componentes estavam documentados. O fluxo principal validado em alta fidelidade.
O próximo passo não era apresentar para um dev. Era eu mesmo colocar em produção.
Utilizei o Antigravity como IDE de orquestração, conectado ao Figma via MCP. (Como explicado acima no Design System).
Isso significa que o modelo não interpretava o design, ele lia os tokens, variáveis e componentes diretamente do arquivo, e traduzia para código respeitando o sistema que eu havia construído.
Stack:
- Frontend: React + Vite + TailwindCSS
- Backend e Banco de dados: Supabase (PostgreSQL + Edge Functions + Auth)
- Deploy: Vercel
- IA integrada: Google Gemini 2.5 Flash via Supabase Edge Functions
- Rastreamento de eventos: Tabela
user_eventscustomizada no Supabase (Apenas para usuários com privilégio admin).
A decisão de usar Supabase como backend não foi só técnica, foi de produto.
O sistema de user_events que implementei permitiu rastrear cada interação relevante do usuário em produção: inícios de fluxo, submits, abandonos, erros. Isso transformou o app num produto observável desde o início.
O resultado: um MVP mobile-first funcional, com autenticação, banco de dados em produção e rastreamento de comportamento ativo, construído inteiramente dentro do workflow design → código → dados.
6 — O Gargalo Identificado - Quando os Dados Contradizem o Design
Após as primeiras semanas de uso real com usuários beta, acessei a tabela user_events no Supabase esperando validar o fluxo que havia desenhado com cuidado.
Os dados não confirmaram. Eles acusaram.
O diagnóstico:
| Métrica | Valor |
|---|---|
| Taxa de conversão no fluxo de nova transação | 37,5% |
Taxa de abandono explícito (new_transaction_abandon) |
50% |
| Padrão comportamental identificado | Múltiplos submit sob o mesmo session_id |
O padrão de múltiplos submits sob o mesmo session_id em sequência curta era o sinal mais revelador: usuários clicando repetidamente no botão salvar sem receber feedback de carregamento: um formulário ansioso gerando usuários ansiosos.
Mas o problema mais profundo estava na arquitetura do fluxo.
A barreira estrutural:
O modal de nova transação exigia que o usuário selecionasse uma categoria e uma conta antes de salvar. Correto do ponto de vista de dado. Problemático do ponto de vista de experiência.
Usuários que ainda não tinham categorias ou contas cadastradas eram forçados a:
- Fechar o modal no meio do registro
- Navegar para outra tela para criar a categoria ou conta
- Voltar para o modal e recomeçar do zero
O dado confirmava: o abandono não era falta de intenção. Era uma barreira de arquitetura disfarçada de campo obrigatório.
O usuário queria registrar. O produto não deixava
7 — A Iteração e os Dados - Intervir no Lugar Certo, Medir o Resultado
Com o diagnóstico claro, a solução não era redesenhar o fluxo inteiro. Era remover a fricção exata que os dados apontavam.
A solução:
1. Criação inline de categorias e contas
O usuário passou a criar categoria ou conta diretamente dentro do modal, sem interromper o fluxo. Nenhum redirecionamento, nenhuma perda de contexto. O campo que antes bloqueava o registro virou um ponto de criação rápida.
2. Feedback visual de carregamento
Estados de loading e validações imediatas foram adicionados ao formulário.
O padrão de múltiplos submits —> sinal de incerteza foi eliminado na raiz.
O resultado medido:
| Métrica | Antes | Depois | Variação |
|---|---|---|---|
| Taxa de conversão | 37,5% | 90% | +53 pp |
| Taxa de abandono | 50% | 10% | -40 pp |
| Padrão de submit | Múltiplos por sessão | 1 start : 1 submit | Estabilizado |
A evidência mais limpa não veio dos percentuais, veio do comportamento nos logs.
Em março, o mesmo session_id registrava três, quatro, cinco new_transaction_submit em sequência.
Em abril, o padrão voltou ao esperado: um início, um submit, uma conclusão. O fluxo parou de gerar ansiedade porque parou de gerar dúvida.
Fonte: tabela user_events, Supabase. Período: março–abril 2026. Base: 36 inícios e 24 conclusões rastreados. 
O modal de criação de conta ainda registrava 55% de drop-off no período, o maior gargalo identificado no produto.
A análise do componente AddAccountModal.tsx revelou campos técnicos como closing_day e due_day sem contexto explicativo, e validação disparada apenas no submit. As correções de severidade alta foram implementadas em 06/04. Próximo ciclo com base maior confirmará ou refinará.
Esse é o ciclo: diagnosticar, priorizar, intervir, medir, repetir.
8a — Scan de Nota Fiscal - Quando o Maior Atrito é o Registro em Si
A pesquisa havia identificado que um dos principais inimigo da retenção em apps financeiros não é a falta de funcionalidade é o esforço repetitivo de registrar cada transação manualmente.
Digitar estabelecimento, valor, data e categoria toda vez que se faz uma compra é exatamente o tipo de fricção que faz o usuário desistir do hábito antes de ele se formar.
A resposta foi construir um fluxo de OCR inteligente integrado ao Gemini 2.5 Flash: o usuário tira uma foto do cupom fiscal e o formulário é preenchido automaticamente em menos de 3 segundos.
A decisão técnica:
OCRs tradicionais leem texto. O Gemini interpreta contexto.
A diferença prática: um OCR comum retorna uma string com todo o conteúdo do cupom.
O Gemini consegue distinguir o nome do estabelecimento do endereço, identificar a data em qualquer formato, e o mais relevante para o produto categorizar a compra automaticamente com base nos itens listados.
A arquitetura:
- Câmera nativa (
capture="environment") - Compressão de imagem no cliente (
JS) - Supabase Edge Function (
Deno) —scan-receipt - Google Gemini 2.5 Flash com prompt estruturado
JSON→{ amount, date, title, categoryName }- Auto-fill do formulário
React
O ponto crítico do sistema é o prompt engineering: a Edge Function envia a imagem com instruções que forçam o modelo a retornar exclusivamente um JSON estruturado sem texto adicional, sem formatação extra.
Isso garante que o mapeamento para o estado do formulário seja direto e previsível, sem parsing frágil.
O fluxo do usuário:
- Toca no ícone de câmera dentro do modal de nova transação
- Tira a foto do cupom
- O formulário é preenchido automaticamente
- Revisa e confirma
O que antes eram 6 campos manuais virou 1 toque e 1 confirmação.
A funcionalidade foi construída sobre a base sólida do MVP, não como feature de lançamento, mas como evolução natural após o fluxo principal estar estável e medido.
8b — Calculadora de Rolê - O Problema que Acontece na Mesa do Bar
A pesquisa revelou um dado que parecia periférico mas se mostrou central: 12 de 17 usuários relataram dificuldade para dividir contas em grupo.
Não é um problema de matemática. É um problema de contexto, você está no bar, todo mundo olhando, a conta chegou, e ninguém quer ser aquela pessoa que demora calculando no papel.
Os apps que resolvem isso existem. O Splitwise funciona. Mas nenhum deles conversa com o seu controle financeiro pessoal. Você divide a conta, esquece de registrar, e o gasto some do seu histórico.
A Calculadora de Rolê nasceu dessa lacuna: divisão de contas integrada ao ecossistema financeiro do usuário.
A decisão técnica mais importante: simplificação de dívidas
O problema de dividir contas em grupo parece simples mas tem complexidade escondida. Quando cinco pessoas pagam coisas diferentes em momentos diferentes, o número de transferências necessárias para acertar tudo cresce exponencialmente.
A solução foi implementar um algoritmo de simplificação de dívidas, em vez de registrar cada débito individualmente, o sistema calcula o balanço líquido de cada participante e minimiza o número de transferências necessárias.
Na prática: se o Membro A deve ao B, e o B deve ao C, o sistema calcula diretamente que o A paga o C, eliminando uma transação inteira.
A arquitetura de componentes:
A calculadora foi construída como uma Funnel State Machine, uma máquina de estados em passos sequenciais que garante que o usuário nunca se perca no meio de um cálculo complexo.
A jornada da divisão ao controle:
-
CreateRole— Definição do grupo, membros e método de divisão -
AddExpense— Registro do valor bruto e quem realizou o pagamento -
Result— Cálculo instantâneo do balanço de dívidas e créditos
Cada tela é um módulo independente. O estado global do rolê é mantido via contexto React e passado de forma controlada entre os passos sem estado global desnecessário, sem prop drilling profundo.
Três tipos de divisão suportados:
- Equitativa — divide o total igualmente entre todos
- Por item — cada um paga o que consumiu, essencial para restaurantes
- Ajuste fino — valores exatos ou porcentagens por participante
A integração que fecha o ciclo
O diferencial da Calculadora de Rolê não é a divisão em si, é o que acontece depois.
Ao finalizar o cálculo, o sistema consome os family_members já cadastrados no Purso e oferece ao usuário registrar automaticamente a transação no histórico financeiro pessoal de quem pagou.
O gasto que antes sumia entre o bar e o app agora fecha o ciclo dentro do produto.
O fluxo do usuário:
- Nomeia o evento : “Festa Fim de Ano”
- Adiciona quem pagou o quê
- O sistema exibe visualmente quem deve para quem e o saldo líquido de cada um
- Ação rápida para registrar a liquidação diretamente no histórico
Finanças sociais não eram um nice-to-have na pesquisa eram o segundo maior ponto de dor. A calculadora de rolê existe porque o dado pediu, não porque a ideia parecia legal.
9 - O que esse projeto prova - O Ciclo Completo
O que esse projeto demonstra:
Visão de produto antes de execução. A pesquisa com 17 usuários, o benchmarking e a priorização de MVP existem para provar que nenhuma tela foi desenhada por intuição. Cada decisão de interface tem uma origem rastreável.
Design system como contrato, não como documento. Variáveis, tokens e componentes foram construídos para ser lidos por um modelo de IA, e funcionaram como restrição criativa, não como burocracia. O resultado foi consistência visual em escala sem custo de manutenção manual.
Código como extensão do design. A integração com Gemini via Edge Functions, o sistema de user_events, a criação inline no modal — nenhum desses foi pedido para um desenvolvedor. Foram decisões de produto executadas diretamente por quem desenhou o fluxo.
Dados como ferramenta de humildade. A taxa de conversão de 37,5% não foi escondida. Foi o ponto de partida da iteração mais importante do projeto. Um produto que não se mede não evolui ele só acumula suposições.