Neste artigo, acompanhamos a jornada de Gustavo Dev Doido (Gustavo Miranda) no desenvolvimento do aplicativo de agendamentos Belezix, abordando desafios práticos de onboarding, arquitetura, performance e aprendizado contínuo no período de 2019 a 2021. As lições detalhadas a seguir se baseiam nos insights do vídeo TODO APP DE AGENDAMENTO TEM QUE TER ISSO! (IMITANDO PODEROSÍSSIMO NINJA), incluindo exemplos reais, erros cometidos e refatorações necessárias para tornar o produto viável e competitivo.
O que é o Belezix: contexto e propósito
O Belezix nasceu para ser uma solução robusta e automatizada de agendamentos online, focando em facilitar a rotina de salões, estabelecimentos e clientes. O desenvolvimento ocorreu entre outubro de 2019 e setembro de 2021, culminando no lançamento oficial na Play Store para Android, alcançando rapidamente entre 500 a 600 usuários cadastrados.
A solução foi inspirada por demandas reais: permitir que qualquer cliente agende serviços com poucos cliques, enquanto donos de estabelecimentos consigam gerenciar facilmente seus horários, profissionais e atendimentos. No entanto, os desafios encontrados ampliaram o escopo e aprofundaram o entendimento sobre usabilidade e arquitetura backend.
Desafios do cadastro e onboarding: aprendizados dolorosos
O problema do abandono no início do uso
O ponto crítico identificado logo após o lançamento foi o alto índice de desistência. Usuários baixavam o app, completavam parcialmente o cadastro e, em poucos minutos, simplesmente desinstalavam sem retornar. A causa central foi a falta de compreensão do fluxo mínimo necessário para colocar o sistema em funcionamento.
Diversos usuários preenchiam apenas dados básicos (nome, endereço, horários), mas ignoravam telas essenciais como cadastro de profissionais e serviços. Resultado: agendamento impossível e experiência frustrante. Em meio a 80 usuários testados, apenas um chegou a criar o profissional — item indispensável para agendar qualquer serviço.
Outros padrões percebidos:
- Erro ao não criar serviço ou criar apenas um, e não associá-lo corretamente.
- Falta de aviso sobre obrigatoriedade de certos passos antes do agendamento.
- Interface excessivamente fragmentada, obrigando o usuário a navegar por várias telas sem orientação clara sobre prioridade ou sequência.
Fragmentação e fluxo confuso
A experiência inicial exigia que o usuário passasse manualmente por:
- Cadastro de horário de funcionamento (geralmente das 8h às 18h)
- Cadastro de pelo menos um profissional
- Cadastro de um ou mais serviços
- Escolha de uma categoria
- Associação cliente/proprietário
Esse fluxo, repetitivo e mal sinalizado, gerava desistência massiva.
Lições práticas do desastre
- Nunca espere que o usuário deduza sozinho o que é necessário: demonstre caminhos, crie exemplos e automatize etapas críticas.
- Reduza drasticamente o número de passos obrigatórios antes do usuário perceber valor na aplicação (“tempo até o valor percebido”).
- Divida cadastros em fluxos intuitivos: proprietário (owner) x cliente (client), com exigências e automações adequadas para cada perfil.
Reviravolta no backend: automatização total no onboarding
O principal salto de qualidade veio ao refatorar o backend para automatizar rotinas de cadastro e minimizar a complexidade inicial. Assim que um novo usuário (tipo owner) faz o registro, o sistema — via backend — cria automaticamente todas as entidades essenciais, sem exigir múltiplos cliques:
- Profissional padrão
- Serviço padrão (exemplo: "Corte de Cabelo")
- Categoria padrão (exemplo: "Beleza Estética")
- Horários pré-definidos (8h às 18h)
- Um cliente associado para permitir testes imediatos
Essa reestruturação foi implementada usando funções e factories genéricas, mantendo o código flexível e reaproveitável, além de simplificar o onboarding para os novos usuários.
Detalhe do fluxo automatizado
O endpoint de cadastro (completeOwner) recebe as informações básicas do futuro administrador e, via funções utilitárias e Promise.all, executa simultaneamente:
- Criação do registro do usuário
- Geração do profissional
- Setup do serviço
- Criação da categoria
- Associação de cliente
- Configuração do horário default
Isso garantiu que, logo ao finalizar o registro, o usuário já estivesse apto a agendar ou testar — eliminando a principal fonte de frustração inicial.
Resultados após automatizar
- Redução drástica do tempo e esforço para experimentar o app
- Menos abandono logo após cadastro
- Rapidez no preenchimento: cadastro proprietário leva cerca de 15 segundos, enquanto cadastro de cliente comum cerca de 11 segundos
Para escalabilidade futura, todas essas operações já nasceram pensadas para paralelização, facilitando o tratamento assíncrono e uso de brokers.
Futuras integrações e brokers: CFCA/Kafka
Desde a concepção do novo backend, o Belezix já foi formatado para tirar proveito de brokers (exemplo: Kafka/CFCA, que no vídeo recebe o apelido de "kafica"). O objetivo é mover processos demorados (envio de e-mail, notificações push, integrações externas) para processamento em background sem afetar o onboarding.
Como funciona e por que é importante
- Processos críticos (criação principal do usuário e dados relacionados) são instantâneos e não dependem do sucesso de mensagens em background.
- Se algum processamento assíncrono falha, o usuário não é barrado — garantindo uma experiência sem bloqueios críticos.
- Com crescimento de usuários e volume, a separação entre onboarding e tarefas pesadas é um diferencial de escalabilidade.
No futuro, pretende-se ampliar o uso de brokers para gerenciar filas de tarefas, melhorar notificações, escalabilidade e integrações com outros sistemas.
Arquitetura, tecnologias e padrões aplicados
O desenvolvimento do Belezix foi pautado por um ciclo intenso de refatorações. Alguns pilares:
Principais termos e tecnologias
- MVP (Minimum Viable Product): sempre priorizar o recurso mínimo para entregar valor rápido.
- GitHub: versionamento e organização do código em controllers, factories e use cases. Diversas branches específicas para testes e correções (ex: "aula 93").
- MongoDB: segmentação clara de entidades (user, owner, client, service, category), evitando o “caos organizado” típico dos bancos NoSQL.
- Kafka/CFCA: preparação e testes para suportar a maior carga e novas features assíncronas.
- Clean Architecture: divisão de responsabilidades; preferência por arrow functions nos use cases, reduzindo dependências de classes e tornando o código mais simples de manter.
- SOLID, Design Patterns: abordagem pragmática, usando patterns como Chain of Responsibility apenas quando necessários (ex: atualização de solicitações por ID).
Exemplo prático de fluxo no backend
Ao cadastrar um proprietário, o backend executa, paralelamente:
- Registro do usuário e dependências
- Horário padrão
- Profissional padrão
- Serviço default ("Corte de Cabelo")
- Cliente associado
- Categoria “Beleza Estética”
As operações são feitas via factories e controllers próprios, que gerenciam dependências entre tabelas e garantem tipagem consistente. Ajustes e correções se concentravam em entidades e repositórios com base em erros reais encontrados (ex: integração entre campo myOwnerId e entidades ligadas ao usuário).
Engenharia, testes e ramificações
- Exemplos de cadastro, login e testes utilizavam nomes como Gustav Miranda, Gustavo Miranda 12, Jason Vamos, Maluco Outra.
- Emails genéricos e combinações de senha como "100 1 2 3 4 5 6" foram usados para validar diversos cenários.
- Benchmarks reais mostraram cadastros de proprietário em 15s e clientes em 11s.
- Quantitativos como 80, 500, 600, 100, 93, 10 ajudaram a medir conversão e abandono pelo funil de uso.
Outros projetos e experiências transferidas
- Nomes como Beleza Est, AD Honor, AD Service, além do próprio Miranda 12, exemplificam contextos onde essas práticas e fluxos foram reaplicados.
- Cada caso validava conceitos de automação, onboarding guiado e arquitetura com separação de responsabilidades.
Aprendizados, refino contínuo e melhorias futuras
O Belezix é um resumo prático das dores, conquistas e adaptações recorrentes de quem constrói produto digital do zero. Entre os principais aprendizados:
- A compreensão profunda da jornada do usuário determina a retenção e o uso real da ferramenta.
- Automatizar fluxos críticos e criar exemplos para o usuário são diferenciais decisivos no early-stage.
- Separar entidades e responsabilidades facilita manutenção, evolução e escalabilidade do sistema.
- Paralelização e processamento assíncrono (com brokers) preparam o produto para crescer sem gargalos.
Próximos passos e desafios sugeridos
- Ampliar as integrações com brokers para tarefas pesadas em larga escala, como envio de notificações e comunicações externas.
- Compartilhar novas implementações e estratégias por meio de aulas e open source no GitHub.
- Refinar a experiência do usuário, buscando pontos de diferenciação frente a concorrentes dos mercados de agendamento.
Tabela de termos, siglas e exemplos práticos
Termo/Sigla | Explicação ou Contexto
US Case | Caso de uso implementado no backend
CFCA (Kafka/Kafica) | Broker para tarefas assíncronas
MVP | Produto Mínimo Viável
GitHub | Repositório e versionamento
MongoDB | Banco NoSQL usado no projeto
CRC | Pasta/estrutura do código fonte
CTP | Módulo de verificação de email/tipagem
SOLID, Design Patterns | Padrões de arquitetura e prática
GPT | Mencionado no vídeo como "gp trouxa"
Beleza Est | Categoria padrão criada
Miranda 12, Gustav Miranda, Jason Vamos, Maluco Outra | Nomes de teste
Aula 93, aula 100, aula 10 | Branches/exemplos de etapas
AD Honor, AD Service | Casos de uso/camadas de domínio
Referências e fontes
- Vídeo completo: TODO APP DE AGENDAMENTO TEM QUE TER ISSO! (IMITANDO PODEROSÍSSIMO NINJA)
- Gustavo Dev Doido (Gustavo Miranda)
- Branches de exemplos e código em GitHub
Ao longo dessa experiência, fica claro: desenvolvimento de software útil não é feito apenas com código, mas entendendo pessoas, fluxos e a busca incansável por eliminar ruído e simplificar vidas. A lição principal? Sempre pense do ponto de vista de quem vai usar e nunca pare de ajustar o que for necessário para viabilizar o sucesso do seu produto.