AVDR
Guia do mapa
Como usar
O que é. Os 7 pilares de todo app, cada um em quatro partes: o que é, por que importa para você, o que perguntar a quem vai construir e o que usamos aqui.
Para quem é. Para quem vai contratar um app e não é técnico. Você não precisa saber construir. Precisa saber o que perguntar e reconhecer uma resposta vaga.
O que não é. Não é a lista das únicas ferramentas certas. As que aparecem aqui são as que usamos nos projetos da operação, contadas no nosso mapa de código em 15/09/2026. Outras também funcionam; o que pesa é quem constrói saber explicar a escolha.
Como levar para a conversa. Escolha as perguntas que fazem sentido para o seu app. No fim há 7 perguntas, uma por pilar, para conferir antes de assinar.
Pilar 1. Frontend: a cara do app
O que é. Tudo o que o seu cliente vê e toca: telas, botões, menus e formulários.
Por que importa. É a parte que o cliente julga. Se a tela confunde, ele desiste antes de chegar ao resto.
Pergunte a quem vai construir.
- O que aparece na tela enquanto carrega, quando não tem nada para mostrar e quando dá erro?
- Funciona bem no celular? Os botões têm tamanho para o dedo?
- O texto é fácil de ler? O contraste entre letra e fundo foi medido ou só olhado?
O que usamos aqui. Next.js, React e Tailwind. O Next.js aparece em 11 projetos do nosso mapa de código. Nas telas de sistema, a regra da operação é desenhar todos os estados de cada tela (carregando, vazio, erro, sucesso e busca sem resultado) e medir o contraste com conta, nunca no olho.
Libere os pilares 2 a 7
Deixe seu e-mail e abra agora os outros 6 pilares, cada um com as perguntas para fazer a quem vai construir, e as 7 perguntas para conferir antes de assinar. Sem spam: só os próximos guias.
Pilar 2. Backend: o cérebro que ninguém vê
O que é. A parte que roda no servidor, longe da tela: faz as contas, aplica as regras do seu negócio, guarda e busca os dados e conversa com outros sistemas, como pagamento e WhatsApp.
Por que importa. É onde mora a regra do seu negócio: preço, desconto, prazo, quem aprova o quê. Com a regra errada aqui, tela bonita nenhuma resolve.
Pergunte a quem vai construir.
- Onde fica escrita cada regra do meu negócio, e como vocês me mostram que ela funciona do jeito que eu descrevi?
- Quantas pessoas usando ao mesmo tempo isso aguenta hoje, e o que muda se crescer?
- As decisões técnicas importantes ficam registradas por escrito, com as opções descartadas e o motivo?
O que usamos aqui. NestJS, escrito em TypeScript. O NestJS aparece em 5 projetos do mapa. O motivo registrado no nosso padrão de engenharia: ele força organização desde o primeiro dia e deixa a estrutura previsível, o que ajuda também quando a IA escreve parte do código. E toda decisão técnica relevante vira um registro com o contexto, as opções consideradas, a decisão e as consequências.
Pilar 3. Banco de dados: a memória do app
O que é. Onde fica guardado tudo o que o app registra: clientes, pedidos, pagamentos e histórico.
Por que importa. Os dados são do seu negócio. Se somem, vazam ou ficam presos com quem construiu, o prejuízo é seu.
Pergunte a quem vai construir.
- Onde os dados ficam guardados, e em nome de quem está essa conta?
- Existe cópia de segurança automática? Alguém já testou restaurar a partir dela?
- Quando algo é apagado no app, some de vez ou fica guardado? Dá para recuperar o que foi apagado por engano?
- Se um dia eu trocar de fornecedor, recebo os dados num formato que outra equipe consiga usar?
O que usamos aqui. PostgreSQL, com o Prisma fazendo a ponte entre o código e o banco. O PostgreSQL aparece em 5 projetos do mapa e o Prisma em 4, sem contar um projeto que ainda só planeja usar os dois. Duas regras escritas em projetos reais: num app em construção, a cópia de segurança precisa ter a restauração testada antes do primeiro usuário real; noutro, a sincronização de dados nunca apaga um registro de vez.
Pilar 4. Autenticação: quem entra e o que vê
O que é. O login e as permissões. Define quem pode entrar e o que cada pessoa enxerga depois que entra.
Por que importa. O funcionário não vê o que só o dono vê, e um cliente nunca vê os dados de outro. Erro neste pilar aparece como vazamento.
Pergunte a quem vai construir.
- Quais são os níveis de acesso (dono, gerente, funcionário, cliente) e o que cada um vê?
- Como a pessoa recupera o acesso se esquecer a senha ou trocar de celular?
- Se o app atende mais de uma empresa, como vocês provam que uma não enxerga os dados da outra?
- Qualquer pessoa consegue criar conta sozinha? Isso é de propósito?
O que usamos aqui. JWT, o jeito de fazer login do nosso padrão de engenharia (citado em 2 projetos do mapa), e o Better Auth num projeto novo. Na nossa plataforma que atende várias empresas, a separação dos dados entre elas tem teste automático. Um caso real:
- Escolha com custo declarado. Num app em construção, a decisão registrada foi entrar com um código de 6 dígitos pelo WhatsApp, sem e-mail. O custo aceito por escrito: quem perde o acesso depende do dono do negócio para recuperar.
Pilar 5. Pagamentos: como o app faz dinheiro
O que é. Como o app cobra: assinatura mensal, cobrança avulsa, cartão, e o que acontece quando o pagamento falha ou o cliente cancela.
Por que importa. O app precisa saber sozinho quem pagou, quem cancelou e quem ficou devendo. Se isso depende de alguém conferir na mão, vira uma planilha paralela.
Pergunte a quem vai construir.
- O app precisa mesmo cobrar dentro dele, ou a cobrança pode ficar fora no começo?
- Quando o pagamento cai, o que muda no app e em quanto tempo? E quando o cartão é recusado?
- O que acontece com o acesso de quem atrasou? E de quem cancelou? Esse bloqueio começa ligado ou desligado?
- Dá para cobrar um preço diferente de cada cliente?
O que usamos aqui. Stripe, numa conta única da empresa que cobra todos os nossos softwares. Três regras nossas:
- Toda venda leva a etiqueta do produto, para separar o faturamento de cada software na mesma conta.
- Cada app recebe do Stripe o próprio aviso de pagamento e ignora o que não é dele.
- Cada app trava a versão da integração. Numa atualização, um valor que o app lia mudou de nome sem aviso.
No nosso software de assinatura, o bloqueio por falta de pagamento nasceu desligado, e atraso recente não bloqueia: só quem ficou sem pagar ou cancelou. E num piloto, a decisão foi deixar a cobrança fora do app, para ele estrear sem depender de contrato com terceiro.
Pilar 6. Segurança: proteger dados e acessos
O que é. Tudo o que impede que dados vazem, que senhas sejam descobertas e que alguém abuse do app.
Por que importa. Vazamento de dado de cliente vira problema com a LGPD e com a confiança de quem compra de você.
Pergunte a quem vai construir.
- As senhas e as chaves de acesso a outros sistemas ficam fora do código? Onde ficam guardadas?
- O que impede alguém de tentar senha atrás de senha até acertar?
- Existe uma checagem automática que procura senha esquecida no código antes de publicar?
- A senha dos usuários fica guardada de um jeito que nem vocês conseguem ler?
- Quem revisa a segurança é a mesma pessoa que construiu?
O que usamos aqui.
- gitleaks, uma ferramenta que procura senha e chave esquecidas no código. Aparece em 3 projetos do mapa e na checagem de senhas dos nossos arquivos internos.
- Limite de tentativas no login. Num painel nosso: 10 tentativas a cada 5 minutos por endereço de internet.
- Chaves guardadas no cofre do sistema, fora dos arquivos do projeto.
- bcrypt para a senha dos usuários, como manda o nosso padrão: a senha é embaralhada de um jeito que não dá para desfazer.
- Quem revisa não é quem construiu. A auditoria de segurança só lê e aponta; a correção fica com outro responsável.
A lição que ficou: ferramenta ligada não prova que olhou tudo. Por isso a checagem automática não substitui a revisão de quem não construiu.
Pilar 7. Deploy: colocar o app no ar
O que é. Tirar o app do computador de quem construiu e pôr na internet, para as pessoas usarem. Inclui o endereço, o servidor e o jeito de publicar cada atualização.
Por que importa. Se só quem construiu sabe publicar, cada ajuste depende dele. E o endereço escolhido no começo pesa depois.
Pergunte a quem vai construir.
- Onde o app vai rodar, e em nome de quem ficam as contas do servidor, do endereço e do código?
- Existe uma versão de teste para eu aprovar antes de ir para o ar?
- Se a atualização nova der erro, a versão antiga continua funcionando?
- O passo a passo para publicar está escrito? Outra pessoa conseguiria seguir?
- O endereço definitivo do app já está decidido?
O que usamos aqui. O código fica guardado no GitHub (9 projetos do mapa têm repositório lá). Sites e telas são publicados na Vercel (15 projetos do mapa). Sistemas maiores rodam num servidor alugado só nosso, em Docker, com o Coolify na porta de entrada. Regras e fatos reais:
- A regra é ter uma versão de prévia aprovada antes de ir para produção. E já vimos a Vercel publicar direto em produção o primeiro envio de um projeto novo, então isso é conferido a cada projeto.
- Num dos nossos sistemas, se a versão nova não compila, a antiga segue no ar.
- Num app que vai ser instalado na tela do celular, o endereço definitivo vem antes do primeiro usuário, porque trocar depois deixa o ícone instalado sem funcionar.
- Sendo transparente: parte dos nossos passos a passo de publicação ainda está por escrever, e isso está anotado como pendência.
Antes de assinar: 7 perguntas, uma por pilar
- Frontend. O que aparece quando carrega, quando está vazio e quando dá erro?
- Backend. Onde está escrita cada regra do meu negócio?
- Banco de dados. A cópia de segurança já foi restaurada num teste?
- Autenticação. Quais são os níveis de acesso, e quem vê o quê?
- Pagamentos. O que acontece com quem atrasou e com quem cancelou?
- Segurança. Quem revisa a segurança é a mesma pessoa que construiu?
- Deploy. Em nome de quem ficam o servidor, o endereço e o código?
Sinal de alerta. "Depois a gente vê" ou "isso é técnico demais para explicar". Se a pessoa não consegue explicar um pilar numa frase simples, pergunte de novo até entender.