Portal do cliente num fim de semana: o projeto perfeito pra começar

Portal do cliente é o projeto ideal pra estrear em vibe coding porque junta três coisas raras no mesmo pacote: escopo pequeno (3 telas, não 30), dado só de leitura (baixo risco de quebrar algo importante) e uma dor real, o cliente perguntando “cadê meu pedido” por WhatsApp toda semana. Dá pra sair do zero a um portal funcionando num fim de semana com Lovable ou Claude Code, testado com 2 clientes reais no domingo.

Por que o portal do cliente é o projeto ideal pra estrear no vibe coding?

Porque junta baixo risco com dor visível, uma combinação rara em projeto de tecnologia. Três motivos concretos:

• Escopo pequeno: login, uma tela de status, uma lista de documentos. A v1 não tem mais que isso, e não precisa ter.
• Dado read-only: o portal só mostra o que já existe em outro lugar (planilha, CRM, sistema interno), não grava nada novo. Se travar, o pior cenário é o cliente ver uma tela de carregando a mais, não perder informação de verdade.
• Dor recorrente e cara: quase toda PME de serviço tem o mesmo padrão. Cliente manda mensagem perguntando status, alguém para o que tá fazendo pra responder, e isso se repete todo dia da semana.

Hipotético pra deixar concreto: imagina uma agência de marketing com 12 clientes ativos rodando campanha ao mesmo tempo. Hoje o status de cada projeto mora na cabeça do gestor de conta, e o cliente só descobre novidade quando manda mensagem perguntando. Um portal com login e status resolve isso sem tirar ninguém da rotina pra atualizar planilha em dois lugares diferentes.

Não acho que todo negócio precisa de portal do cliente. Pq quem atende 3 clientes por telefone direto não tem esse gargalo, o volume não justifica. O projeto faz sentido quando o “cadê meu pedido” já virou trabalho manual repetitivo, não exceção.

---

Como definir o escopo do portal na sexta à noite?

A sexta à noite não é pra abrir ferramenta nenhuma. É pra decidir o que entra na v1 antes de escrever o primeiro prompt, porque começar pela tela antes de decidir o dado é o erro mais comum desse tipo de projeto.

Escopo mínimo que funciona pra praticamente qualquer negócio de serviço:

1. Login simples: e-mail ou CPF/CNPJ mais um código enviado, sem senha complexa pra ninguém decorar.
2. Status do pedido ou projeto: uma etapa clara (“em produção”, “em revisão”, “entregue”), não 15 substatus internos que só o time entende.
3. Documentos: contrato, nota fiscal, relatório, o que o cliente hoje pede por e-mail ou WhatsApp e alguém tem que ir buscar manualmente.

Hipotético: uma marcenaria sob encomenda decide que o cliente só precisa ver 4 etapas (projeto aprovado, produção, montagem agendada, entregue) e o contrato assinado em PDF. Não precisa de mais que isso pra fechar essa lista na sexta.

A sexta termina com essa lista escrita à mão ou numa nota no celular. Sem isso, o sábado começa perdido e o prompt pra IA sai vago, igual acontece com qualquer outro projeto de vibe coding.

---

Como construir o portal no sábado com Lovable ou Claude Code (login, status e documentos)?

No sábado a ferramenta entra em cena. Manhã (2 a 3 horas) é pra organizar a fonte de dado, seja uma planilha do Google Sheets com o status de cada cliente, seja um export do sistema que já controla pedido ou projeto. Tarde (3 a 5 horas) é pra construir as 3 telas decididas na sexta: login, status, documentos.

Stack: Lovable dá conta bem da parte visual (tela de login, cartão de status). Claude Code lida melhor com autenticação de verdade e upload/organização de arquivo, então rende melhor se o portal precisar de senha por código ou anexo de documento em PDF.

Cria um portal do cliente com 3 telas. 1) Login: cliente entra com e-mail
e recebe um código de acesso por e-mail, sem senha. 2) Status: mostra o
nome do cliente e a etapa atual do pedido/projeto entre estas opções:
[liste suas etapas aqui, ex: em produção, em revisão, entregue]. 3)
Documentos: lista de arquivos (PDF) disponíveis pra download, vinculados
ao cliente logado. Conecta numa planilha do Google Sheets com colunas
cliente, e-mail, etapa e link do documento. Cada cliente só vê os
próprios dados.

No fim do sábado o portal existe e mostra dado, mas ainda não foi testado com cliente de fora da empresa. Isso é proposital: sábado é pra estrutura, domingo é pra estresse com gente real.

Como testar com 2 clientes reais no domingo (e o que vai quebrar)?

O teste de domingo é com 2 clientes de verdade, não com o time interno. O time já sabe o que devia aparecer na tela, o cliente não sabe, e é a reação dele que mostra se o portal resolve a dor ou só parece bonito.

Coisas que costumam quebrar nesse teste:

1. Código de login não chega: e-mail cai em spam ou demora, e o cliente desiste antes de entrar. Ajuste rápido: pedir pra IA revisar o remetente e o assunto do e-mail, ou trocar o canal de envio do código.
2. Nome de status não bate: o time chama de “em produção” internamente, mas o cliente não entende o termo e manda mensagem perguntando o que significa. A correção aqui é de texto, não de código, e costuma resolver em minutos.
3. Documento não abre no celular: boa parte dos clientes vai acessar pelo celular, e um PDF mal formatado ou um botão pequeno demais já é motivo de reclamação.

Sendo bem sincero, se os 2 clientes não usarem o portal sem pedir ajuda por telefone, a v1 ainda não tá pronta. Melhor descobrir isso no domingo do que na segunda com 40 clientes reclamando ao mesmo tempo.

---

O que fica pra v2 e o que não vale a pena construir no fim de semana?

Fica de fora da v1, por bom motivo:

• Pagamento online dentro do portal: mexe com dado financeiro sensível, exige camada de segurança que passa longe de projeto de fim de semana.
• Múltiplos usuários por empresa cliente: se o cliente tem 3 pessoas que precisam acessar com permissões diferentes, isso é v2, a v1 é 1 login por cliente.
• Notificação automática (e-mail ou WhatsApp avisando quando o status muda): útil, mas depende de integração que pede mais tempo de ajuste do que um fim de semana permite.
• Escrita de volta no sistema (cliente aprovando algo que grava no seu CRM ou ERP): a v1 é só leitura de propósito. No momento que o cliente pode alterar dado, o risco de erro sobe de patamar.

Não acho que isso é limitação do vibe coding em si. Pq cada item pede decisão de segurança que exige mais que um sábado guiado por prompt, então empurrar pra v2 é decisão certa, não desculpa.

Vale reforçar: portal do cliente read-only resolve visibilidade. Não substitui um sistema comercial completo tipo o Super SDR, que tem setup de R$8 mil a R$15 mil e infraestrutura de R$550 a R$650 por mês porque já nasce como operação de vendas automatizada rodando todo dia, com escrita de dado e regra complexa. São categorias diferentes de problema.

---

Vale mais um portal feio que funciona ou um portal perfeito que não sai do papel?

A v1 desse projeto vai sair com paleta genérica, sem identidade visual da sua marca, com cara de protótipo. Isso é esperado, não é defeito do processo.

O critério que importa é outro:

• O cliente loga sozinho.
• Vê o status certo.
• Baixa o documento que precisa.

Funcionar resolve a dor de hoje. A cara da sua marca é reforma pra depois, quando você já sabe o que os clientes realmente usam ali dentro.

Hipotético pra fechar concreto: imagina um escritório de projetos de reforma com 15 obras em andamento e um WhatsApp lotado de “como tá minha obra?”. Duas tardes de fim de semana resolvem login, status e documento, sem contratar ninguém, e o número de mensagens repetidas cai já na primeira semana de uso.

FAQ

Portal do cliente com vibe coding é seguro pra dado sensível?

Pra dado que já é read-only e vinculado só ao próprio cliente logado (status do pedido dele, documento dele), o risco é baixo desde que o login realmente separe o acesso por pessoa, cada cliente só vendo os próprios dados. O ponto de atenção é não expor CPF, cartão ou dado financeiro sensível numa v1 de fim de semana. Se o portal precisar disso, entra segurança de acesso mais robusta antes de publicar, e isso já é projeto de desenvolvimento sério, não mais vibe coding de fim de semana.

Lovable ou Claude Code, qual escolher pro portal do cliente?

Lovable resolve bem a parte visual das 3 telas (login, status, documentos) e pede menos familiaridade técnica. Claude Code lida melhor com autenticação de verdade (código por e-mail, sessão por cliente) e organização de upload de arquivo, então rende melhor se o portal precisar de mais controle sobre quem acessa o quê. Não precisa travar na escolha antes de começar: dá pra migrar de um pro outro no meio do sábado se travar num ponto específico.

Quanto custa manter um portal do cliente desse tipo rodando?

Na maioria dos casos, próximo de zero além do que você já paga em Lovable ou Claude Code no plano de entrada, que costuma cobrir um projeto desse porte. Se a fonte de dado for uma planilha ou CRM que você já assina, não tem custo adicional de infraestrutura. O custo real é o seu tempo quando o formato do dado muda ou quando um cliente novo pede uma etapa de status que ainda não existe, o que é manutenção normal.

Preciso de quantos clientes testando no domingo?

Dois já é suficiente pra esse teste. O objetivo não é validação estatística, é ver alguém de fora da empresa navegando sem ajuda, o que já revela a maior parte dos problemas de texto confuso, botão mal posicionado ou etapa de login travando. Testar com mais gente no mesmo fim de semana tende a gerar ruído demais pra ajustar tudo até domingo à noite. Dá pra ampliar o teste na semana seguinte, com o portal já mais estável.

Isso substitui um sistema de atendimento ao cliente completo?

Substitui a parte específica de visibilidade de status e documento, que hoje roda manualmente por WhatsApp ou e-mail. Não substitui um sistema comercial completo com automação de vendas, como o Super SDR, que tem setup de R$8 mil a R$15 mil e infraestrutura de R$550 a R$650 por mês porque cobre uma operação inteira, com escrita de dado e regra de negócio complexa. São ferramentas pra momentos diferentes da relação com o cliente.

E se eu não souber quais etapas de status faz sentido mostrar pro cliente?

Comece pelas etapas que você já usa internamente pra saber “onde tá” cada pedido ou projeto, só simplificando o nome pra alguém de fora entender sem explicação. Se hoje você tem 12 status internos, a versão do cliente costuma caber em 3 ou 4 etapas macro. Errar a nomenclatura na v1 não é problema grave, é só ajustar o texto depois de ver a reação dos 2 clientes testados no domingo.

---

Bora escolher o escopo hoje à noite e testar com 2 clientes reais no domingo?