Construindo o Monora: a ideia

A primeira ideia do Monora era relativamente simples: criar um aplicativo mobile para acompanhar minhas finanças pessoais.

Eu poderia começar abrindo o React Native, criando uma tela de transações e conectando tudo a um banco de dados. Em pouco tempo, provavelmente teria um formulário para registrar receitas e despesas, uma listagem e alguns gráficos.

Tecnicamente, seria um projeto válido.

Mas, como produto, ainda faltava responder à pergunta mais importante:

Que decisão esse aplicativo ajudaria alguém a tomar?

Foi essa pergunta que começou a transformar uma ideia comum de controle financeiro no que hoje estou construindo como Monora.

Registrar gastos não significa compreender o dinheiro

Grande parte dos aplicativos financeiros consegue armazenar informações. O usuário registra uma compra, escolhe uma categoria e, no fim do mês, recebe gráficos mostrando para onde o dinheiro foi.

O problema é que visualizar dados não significa necessariamente saber o que fazer com eles.

Uma pessoa pode descobrir que gastou mais com alimentação e ainda continuar sem respostas para questões muito mais importantes:

• Minha situação está sob controle neste momento?
• Existe alguma conta ou comportamento que exige atenção?
• Quanto posso gastar sem comprometer meus objetivos?
• Qual é a ação mais importante que devo realizar agora?
• Estou realmente evoluindo ou apenas registrando o que já aconteceu?

Além disso, acompanhar cada movimentação pode rapidamente se transformar em trabalho administrativo. Quanto mais cadastros e configurações são exigidos antes que o usuário perceba algum benefício, maior é a chance de abandono.

Eu não queria construir apenas uma planilha com uma interface mais bonita.

A hipótese inicial

A hipótese que passou a orientar o Monora foi:

O acompanhamento financeiro pode ser mais útil quando, além de organizar os dados, ajuda o usuário a entender sua situação e indica uma ação prioritária de cada vez.

Isso mudou a direção do produto.

Em vez de pensar primeiro em quantos gráficos caberiam no dashboard, comecei a pensar nas perguntas que a tela inicial deveria responder. Em vez de apresentar várias recomendações concorrentes, a proposta passou a ser mostrar um único Próximo Passo.

Esse passo pode ser confirmar uma despesa, revisar um saldo, planejar um pagamento ou simplesmente informar que nenhuma ação é necessária naquele momento.

A ideia não é tomar decisões pelo usuário. É reduzir o esforço necessário para que ele compreenda o cenário e decida com mais clareza.

Valor antes da configuração

Outro princípio surgiu do mesmo problema: o Monora não deveria exigir que alguém organizasse toda a vida financeira antes de entregar valor.

Cadastrar contas, cartões, rendas, despesas recorrentes, metas, orçamentos e categorias logo no primeiro acesso pode deixar o sistema completo, mas também transforma o onboarding em um interrogatório.

A direção escolhida foi começar pequeno.

O usuário cria uma conta financeira, registra a primeira movimentação e recebe um primeiro resumo. Recursos adicionais são apresentados progressivamente, conforme passam a fazer sentido para o momento dele.

Essa decisão cria um trade-off: no início, o Monora terá menos informações e precisará comunicar claramente quando seus indicadores ainda forem limitados. Em troca, a pessoa pode perceber valor antes de concluir uma configuração extensa.

Acompanhamento sem culpa

Produtos financeiros lidam com um assunto que já pode carregar ansiedade, frustração e sensação de fracasso. Por isso, a linguagem e as mecânicas do Monora não podem punir alguém por estar desorganizado ou por passar alguns dias sem abrir o aplicativo.

Quando houver uma ausência, a experiência deve ajudar a recuperar o controle: reconciliar movimentações, identificar o que mudou e apresentar a prioridade atual.

O mesmo cuidado vale para a gamificação.

O Monora terá elementos de progressão visual, desafios e conquistas, mas eles devem representar comportamentos financeiros úteis. Abrir o aplicativo todos os dias ou registrar movimentações artificialmente não deveria gerar progresso por si só.

A recompensa precisa vir depois da utilidade.

De uma funcionalidade para um sistema

Ao aprofundar essas decisões, percebi que não estava mais projetando apenas um expense tracker.

O produto começou a se organizar ao redor de um ciclo:

1. Registrar ou confirmar o que aconteceu.
2. Compreender a situação atual.
3. Identificar o que merece atenção.
4. Executar uma ação útil.
5. Revisar a semana e fechar o mês.
6. Perceber a evolução construída ao longo do tempo.

Essa mudança também aumentou a responsabilidade técnica. Transações, contas, cartões, compromissos, orçamentos e metas precisam formar um modelo consistente. Indicadores precisam ser explicáveis. A gamificação não pode contradizer a realidade financeira. E a interface precisa orientar sem esconder as informações que sustentam cada recomendação.

Antes de escrever o código, eu precisava entender o sistema.

Por que estou documentando essa construção

O Monora também faz parte de um objetivo profissional: evoluir minha capacidade de desenvolver produtos de ponta a ponta.

Minha experiência é mais especializada em front-end, principalmente com React, Next.js e React Native. Neste projeto, quero ir além da implementação de interfaces e trabalhar conscientemente com descoberta de produto, definição de escopo, experiência do usuário, arquitetura, modelagem de dados, backend, segurança, testes e entrega.

Também estou estruturando o desenvolvimento para trabalhar com IA de forma mais previsível. Em vez de pedir que um agente gere funcionalidades a partir de descrições vagas, estou criando especificações, regras de negócio, critérios de aceite e etapas claras de validação.

Ao longo desta série, vou compartilhar as decisões por trás do produto, os desafios técnicos, os trade-offs aceitos e também aquilo que mudar durante o caminho.

O Monora ainda é uma hipótese em construção. Não existem métricas de retenção ou promessas de impacto para apresentar. O que existe é um problema que considero relevante, uma direção de produto e um processo de engenharia que poderá ser analisado com transparência.

Este é o ponto de partida.

No próximo artigo sobre o Monora, quero explorar uma pergunta que ajudou a definir todo o restante: o que separa um projeto de portfólio de um produto de verdade?