O protótipo prova a ideia. O produto assume responsabilidade pelo uso repetido, pelos dados e pelo que acontece quando o caminho feliz termina.
A demonstração otimiza para surpresa
Um protótipo bom reduz a distância entre uma hipótese e uma experiência visível. Ele pode usar dados controlados, uma única conta e um ambiente conhecido. Isso não é uma falha. É justamente o que permite aprender rápido.
O problema aparece quando a arquitetura provisória passa a ser tratada como produto porque a interface parece pronta. A qualidade visual esconde credenciais frágeis, estados apenas na memória, permissões implícitas e caminhos que ninguém testou fora da demonstração.
A transição começa reconhecendo que o objetivo mudou. Depois da validação, a pergunta deixa de ser se algo funciona. Ela passa a ser para quem funciona, em quais condições e como o sistema se recupera.
Distribuição muda a arquitetura
Publicar na web é diferente de distribuir um PWA ou um aplicativo nativo. Push notification, compartilhamento de arquivos, permissões, atualização e autenticação social introduzem caminhos que não existem no navegador de desenvolvimento.
No FalaFit e no PortariaGo, builds iOS e Android exigiram carregamento condicional de plugins, configuração de identidade, pipeline de assinatura e tratamento distinto para recursos nativos. A mesma funcionalidade precisa continuar compreensível quando um dispositivo nega permissão ou uma versão antiga permanece instalada.
Distribuição também é manutenção. Uma entrega confiável precisa ser repetível, documentada e automatizada o suficiente para que uma correção não vire uma nova investigação sobre como publicar.
Dados e permissões deixam de ser detalhes
Com um usuário conhecido, quase qualquer consulta parece correta. Com clientes, equipes ou condomínios diferentes, cada tabela precisa responder quem é dono do registro e quem pode vê-lo.
Multi-tenancy não deveria existir apenas como filtro da interface. O isolamento precisa chegar ao banco, às funções e aos arquivos. Políticas RLS, papéis explícitos e validação no servidor reduzem a chance de uma tela nova esquecer uma condição importante.
A mesma lógica vale para exclusão, exportação e auditoria. Produto assume um ciclo de vida completo para o dado, não apenas o momento em que ele entra.
Operação e aprendizado fecham o ciclo
Depois do deploy, o sistema começa a produzir perguntas novas. Onde as pessoas abandonam? Qual etapa demora? Que erro se repete? A resposta exige eventos, logs e uma forma de relacionar comportamento técnico à jornada.
No Disparador, fila, tracking e analytics fazem parte do produto porque enviar sem entender resultado resolve apenas metade do problema. Em aplicativos, métricas de uso e histórico de falhas mostram se uma funcionalidade está sendo encontrada e concluída.
Produto não significa adicionar todas as funcionalidades possíveis. Significa construir um ciclo confiável de uso, observação, decisão e nova entrega. Essa capacidade de continuar melhorando vale mais do que a quantidade de telas no primeiro lançamento.
Sinais de que a ideia está virando produto
- Autenticação e permissões são verificadas fora da interface
- Dados importantes sobrevivem a recarregamento, falha e troca de dispositivo
- Estados de erro e recuperação foram desenhados
- Publicação pode ser repetida com segurança
- Métricas ajudam a escolher a próxima melhoria
