Pitch: Plopino — do arquivo HTML a um link para revisão

Estou construindo o Plopino, uma ferramenta para transformar um HTML que já existe em um link de visualização. A ideia surgiu de uma etapa pequena, mas frequente: a página está pronta no computador e alguém precisa revisá-la no celular, sem receber um ZIP ou configurar um ambiente.

Um primeiro teste sem framework

Salve isto como index.html (troque os textos pelos do seu exemplo):

<!doctype html>
<html lang="pt-BR">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>Prévia de proposta</title>
<main>
  <h1>Proposta — versão de demonstração</h1>
  <p>Objetivo: revisar o escopo, sem efetuar uma compra.</p>
  <details>
    <summary>Ver entregas</summary>
    <ul><li>Uma página</li><li>Uma rodada de revisão</li></ul>
  </details>
</main>
</html>

Abra o arquivo localmente e clique em “Ver entregas”. O elemento details permite testar uma interação nativa, sem JavaScript, servidor ou dependência externa.

Depois, abra Plopino, envie o HTML e copie o link de visualização. Abra esse link em outro navegador, sem estar conectado, antes de enviá-lo a alguém. Se o projeto usar imagens ou CSS separados, envie a pasta completa ou um ZIP com esses arquivos; um HTML não contém automaticamente os arquivos que ele referencia.

Quando esse fluxo ajuda

Uma proposta com seções expansíveis, um protótipo estático, uma página de documentação pequena ou um relatório exportado para HTML. O destinatário abre a página e pode usar suas interações no navegador. A criação do conteúdo continua no editor que você já usa; o Plopino cuida da etapa de compartilhar.

Para uma revisão pontual, o envio anônimo gera um link público com retenção de 30 dias e limite de 5 MB por arquivo. Para manter um material ao longo do tempo, uma conta permite salvar e gerenciar o board, atualizar seu conteúdo mantendo o mesmo endereço de visualização e usar arquivos de até 50 MB. O armazenamento da conta não tem a expiração de 30 dias do fluxo anônimo.

Limites que mudam a escolha

É hospedagem de conteúdo estático. HTML, CSS e JavaScript executado no navegador não substituem um backend: esse exemplo não recebe pagamentos, salva respostas ou autentica clientes. Se a página depender de APIs, elas precisam existir separadamente.

O fluxo anônimo é público, então use dados fictícios em demonstrações. Um link difícil de adivinhar não é controle de acesso. E, se cada alteração precisa passar por build, testes e revisão em equipe, um fluxo de deploy conectado ao repositório pode fazer mais sentido.

A decisão de produto foi reduzir a distância entre “tenho um arquivo” e “outra pessoa consegue abri-lo”. O que estou tentando entender agora é onde essa conveniência termina: para uma revisão rápida, vocês preferem enviar um link navegável, um PDF ou o projeto completo?