Faz sentido desenvolver um player de vídeo com compra internamente?
Faz sentido em pouquíssimos casos: quando vídeo é parte central do produto da empresa, quando existe equipe de front-end permanente com capacidade sobrando e quando a operação já mantém infraestrutura de mídia própria. Fora desses casos, o cálculo engana. A primeira versão sai em um sprint e funciona. O custo aparece depois, em transcodificação para múltiplos formatos, entrega por CDN, carregamento sob demanda, comportamento em navegadores diferentes, painel para o time de marketing operar sozinho, relatório por vídeo e compatibilidade com cada atualização de tema e de plataforma. Nenhum desses itens é difícil isoladamente; juntos, formam um produto que alguém precisa manter para sempre.
A lista de coisas que aparece depois do primeiro deploy
A demonstração interna quase sempre é um player exibindo um MP4 hospedado no mesmo servidor da loja, com um botão que chama a API de carrinho. Funciona, impressiona na reunião e cria a impressão de que o problema está resolvido. O que vem depois é uma sequência previsível de descobertas.
Primeiro aparece o peso. Um MP4 servido do mesmo host da loja compete por banda com o resto da página e não tem versão adequada para conexão ruim. Aí entram transcodificação em múltiplas resoluções, empacotamento adaptativo, CDN e carregamento sob demanda. Cada item é uma decisão de infraestrutura com custo recorrente.
Depois aparece o operador. Quem sobe vídeo novo, vincula produto, troca a ordem do carrossel e desativa a peça que saiu de linha? Se a resposta for "abre um card para o dev", o recurso morre por atrito em dois meses. Um painel de operação é, na prática, metade do projeto, e é a metade que ninguém estima.
Por último aparece a manutenção invisível. A plataforma atualiza o tema, o navegador muda a política de autoplay, o time troca de agência, o desenvolvedor que escreveu tudo sai da empresa. Cada um desses eventos é uma nova rodada de trabalho em um componente que não gera receita direta e por isso perde prioridade toda vez.
Comparativo por custo real de ciclo de vida
A tabela olha os três anos seguintes, não a primeira semana. A coluna do desenvolvimento próprio ganha em duas linhas importantes.
| Critério | Desenvolvimento próprio | App de video commercerecomendado |
|---|---|---|
| Tempo até a primeira versão no ar | Semanas de squad | Dias, ativação pelo painel |
| Controle total sobre o código | Ganha, é seu | Limitado ao que o app oferece |
| Customização fora do padrão | Ganha, faz o que quiser | Depende do roadmap do fornecedor |
| Transcodificação e entrega por CDN | Você monta e paga | Incluída |
| Painel para o time de marketing operar | Precisa ser construído | Pronto |
| Relatório por vídeo | Instrumentação manual | Pronto |
| Quem mantém quando o dev sai | Ninguém, na prática | O fornecedor |
| Atualização de tema ou de plataforma | Novo trabalho a cada vez | Responsabilidade do app |
| Custo aparente no orçamento | Zero, some no custo do time | Assinatura visível |
| Custo de oportunidade do squad | Alto, sai de outra entrega | Nenhum |
| Risco de o projeto ser abandonado | Alto, é o primeiro a perder prioridade | Baixo |
A linha de custo aparente é a que mais engana. Hora de squad já paga não aparece na planilha, mas é o recurso mais escasso da operação e sai de outra entrega.
Operações que preferiram não construir
Mais de 20 mil lojas usam o iShorts, incluindo operações com time técnico próprio.
Quando construir internamente é a decisão certa
Existem cenários legítimos para o desenvolvimento próprio. Vale reconhecê-los em vez de fingir que a resposta é sempre a mesma.
Construa você mesmo
- Vídeo é parte central do produto da empresa, não um recurso da loja
- Existe equipe de front-end permanente, com capacidade real sobrando
- A operação já mantém pipeline de mídia e CDN por outros motivos
- A necessidade é tão específica que nenhum fornecedor cobre
- Há restrição regulatória que impede script de terceiro na vitrine
Contrate e economize o squad
- O time de tecnologia já tem backlog maior do que a capacidade
- A loja roda em plataforma SaaS que atualiza tema periodicamente
- Quem vai operar os vídeos é marketing, não desenvolvimento
- A prioridade é medir efeito em semanas, não entregar um projeto
- Não existe ninguém designado para manter o componente em dois anos
Antes de abrir o card no backlog
Veja o que já está pronto rodando no seu catálogo, e compare com o escopo que você ia estimar.
A pergunta que resolve a discussão em uma reunião
Quando a decisão empata, uma pergunta costuma desempatar: quem é a pessoa nomeada, com nome e sobrenome, responsável por esse componente daqui a dezoito meses? Se não existe resposta, o projeto é um passivo, não um ativo. Componente sem dono claro não sobrevive a duas trocas de prioridade.
A segunda pergunta é sobre o que deixa de ser feito. Semanas de squad têm custo de oportunidade concreto: uma integração de ERP que não sai, uma melhoria de checkout que fica para o próximo trimestre, uma correção de busca interna que continua incomodando. Comparar assinatura contra "zero" é errado; o correto é comparar assinatura contra a entrega que foi adiada.
A terceira é sobre reversibilidade. Cancelar uma assinatura é uma decisão de um dia. Descontinuar um componente interno significa remover código do tema, migrar vídeos, decidir o que fazer com a mídia hospedada e ainda assim manter algo no ar até a substituição estar pronta. As duas escolhas têm saída, mas não com o mesmo esforço.
Perguntas frequentes
Provavelmente consegue, e a dificuldade não é o ponto. O ponto é manutenção: transcodificação, CDN, carregamento sob demanda, painel de operação, relatório por vídeo e compatibilidade com cada atualização de tema. Nenhum item é complexo isolado, mas o conjunto é um produto com dono permanente.
Deixa, e é honesto reconhecer. O que reduz esse risco é escolher fornecedor que não modifica seu tema, que usa o carrinho nativo da plataforma e que não deixa código residual. Assim, sair significa desativar o app, não desfazer alterações no seu código.
Essa é a vantagem real do desenvolvimento próprio e vale considerar. A pergunta a fazer antes é se essa customização move alguma métrica ou se é preferência de layout. Na maior parte dos casos é a segunda, e não justifica assumir a manutenção de um componente.
Some, no lado do desenvolvimento próprio, as horas da construção, o custo mensal de armazenamento e CDN, as horas de manutenção por ano e o custo de oportunidade do que o squad deixou de entregar. Compare esse total com a assinatura em três anos, não em um mês.
Depende de como ele foi construído. Se a instalação exige colar snippet no tema, atualização de tema pode desativar o recurso. Se a integração usa o fluxo oficial de aplicativos da plataforma, sem editar tema, a atualização não afeta, e manter a compatibilidade é responsabilidade do fornecedor.
Dá, e é uma sequência sensata. O app entrega dado rápido sobre o que funciona no seu catálogo, e esse dado é exatamente o que faltaria para especificar um desenvolvimento interno com escopo realista. Construir primeiro e descobrir depois é o caminho mais caro.
