Aplicativo dá dinheiro?

Resumo do episódio 73 do AguiarDev Talks. Prefere assistir? Veja o episódio completo →

Todo desenvolvedor já teve aquela ideia de app que ficou só na cabeça. Neste episódio, Claudio Oliveira, com mais de 14 anos de experiência e hoje focado em Flutter, contou como saiu do zero até construir o Reft — um aplicativo de treinos para academia com mais de 8.500 usuários únicos — passando por validação, escolhas técnicas, publicação nas lojas e monetização.

O que foi discutido

• Origem da ideia — nasceu de uma dor pessoal: o app da academia que Claudio usava não salvava seus treinos nem deixava consultar o histórico de meses anteriores.
• Validação antes de codar — conversas com pessoas próximas que também treinavam, para checar se existia um mercado real e um diferencial (o componente social) que ainda não tinha sido explorado.
• Escolhas de stack — Flutter no front, NestJS no back, Google Cloud na infra, decisões guiadas por familiaridade e pelos créditos gratuitos que sustentaram os primeiros meses.
• Desenvolvimento assistido por IA — o projeto inteiro foi construído com agentes de IA organizando o contexto do código, o que permitiu lançar o app em dois meses.
• Publicação nas lojas — o processo de configurar assinaturas foi o ponto mais difícil, especialmente na Apple, com aprovações que pareciam travadas sem motivo aparente.
• Modelo de monetização — assinatura recorrente desde o início, com uma versão gratuita generosa para atrair usuários e converter aos poucos.
• Recebimento de pagamentos internacionais — o trâmite de câmbio para receber valores pagos via App Store, incluindo abertura de conta em uma corretora específica.
• Mudança de perspectiva como dono do produto — como ter o próprio negócio alterou o senso de urgência e a forma de priorizar problemas frente a quando era "só" desenvolvedor.

Sobre Claudio Oliveira

Claudio Oliveira é desenvolvedor com 14 anos de experiência, boa parte dela migrando entre stacks como full stack até decidir, em 2019, focar exclusivamente em Flutter. Ao longo da carreira teve vários projetos pessoais que nunca deram certo comercialmente, até criar o Reft, seu primeiro aplicativo lançado e monetizado com sucesso. Hoje concilia um trabalho PJ com o desenvolvimento do Reft, que já conta com um sócio responsável pela parte de infraestrutura, e segue ativo tanto na parte técnica quanto na de negócio do produto.

Principais pontos

A dor pessoal como ponto de partida

A ideia do Reft não nasceu de uma pesquisa de mercado, mas de um incômodo recorrente: o app da academia que Claudio usava não permitia salvar substituições de exercícios nem manter o progresso de carga entre uma sessão e outra. O estopim final foi não conseguir consultar o histórico de treinos de meses anteriores. Esse tipo de frustração cotidiana — resolver o próprio problema antes de pensar em terceiros — foi o que deu ao projeto uma direção clara desde o início, em vez de mais uma ideia abstrata que nunca sai do papel.

"Eu quero fazer um aplicativo para eu usar e eu realmente uso" — Claudio Oliveira

Validar não precisa ser complexo

Antes de escrever a primeira linha de código, Claudio já tinha as telas na cabeça, mas ainda assim buscou confirmar se havia mercado: perguntou a pessoas próximas, que também treinavam, se conheciam algum aplicativo parecido. Ao descobrir que ninguém usava nada muito específico — só apps genéricos de academia (white label) —, entendeu que havia espaço, mesmo sem uma pesquisa formal ou um MVP elaborado. A validação, nesse caso, foi rápida e conversacional, não um processo longo de meses.

"Eu vi que tinha gente próxima que treina e não conhece o aplicativo de treino, eu falei: tem um mercado ainda" — Claudio Oliveira

IA como acelerador, não como atalho mágico

O Reft foi o primeiro projeto de Claudio pensado desde o início para ser construído com apoio intensivo de IA — organizando o código em pastas para dar contexto claro aos agentes e usando prompts como ponto de partida do desenvolvimento. O resultado foi um app funcional lançado em dois meses de trabalho, incluindo período de férias dedicado exclusivamente ao projeto. Mas o ganho de velocidade não eliminou desafios: a parte mais difícil não foi codar, e sim lidar com a burocracia de configurar assinaturas nas lojas, sobretudo na Apple.

"Minha primeira linha de código na verdade foi um prompt" — Claudio Oliveira

Monetização com liberdade gera mais conversão do que restrição

Claudio optou por assinatura recorrente desde o começo, buscando previsibilidade de receita. Mas, em vez de bloquear funcionalidades logo de cara, deixou o plano gratuito bastante permissivo — permitindo, por exemplo, importar treinos prontos sem limite. Essa escolha, mesmo soando contraintuitiva, ajudou a atrair mais usuários; a conversão para pago acontece de forma orgânica, conforme a pessoa vê valor em recursos como geração de treino com IA ou controle de hábitos, sem nunca ser barrada abruptamente com uma tela de pagamento.

"Eu deixo lá o que é seu treino, do jeito que você quiser usar, e aí você paga — esse é o lance" — Claudio Oliveira

Ser dono muda o senso de urgência, não a essência do trabalho

Ao comparar sua rotina como funcionário e como dono de produto, Claudio destacou que o que mudou não foi a natureza das tarefas, mas o nível de responsabilidade percebida diante de um problema. Um bug que impedia usuários de fazer login virou uma emergência resolvida em tempo real, de madrugada — algo que, como funcionário, talvez não gerasse a mesma urgência por falta de visibilidade do impacto real. Essa mudança de perspectiva, segundo ele, também passou a influenciar como encara tarefas no trabalho formal.

"O meu senso de urgência por ser o dono acaba sendo muito maior do que quando eu sou só um dev" — Claudio Oliveira

Frase de destaque

"Antes da era da IA, era muito difícil eu conseguir começar e terminar um projeto" — Claudio Oliveira

Lições do episódio

1. Um problema pessoal recorrente é, muitas vezes, a validação mais confiável de que existe demanda — não é preciso pesquisa de mercado elaborada para começar.
2. Organizar o código pensando no contexto que os agentes de IA precisam acessar pode acelerar drasticamente o tempo de desenvolvimento de um MVP.
3. Restringir demais o plano gratuito nem sempre converte mais — dar liberdade de uso pode atrair uma base maior que converte naturalmente com o tempo.
4. A burocracia de lojas de aplicativos (assinaturas, aprovação, câmbio internacional) costuma ser mais desafiadora do que o desenvolvimento técnico em si.
5. Ter um produto próprio muda o senso de urgência diante de problemas — a percepção de impacto real tende a ser maior do que a de um funcionário.
6. Definir um prazo claro para validar uma ideia (1 a 3 meses, por exemplo) evita ficar preso indefinidamente em um projeto que não decola.