Quando construir uma plataforma

Plataforma interna é a camada que faz os times de produto entregarem sem precisar dominar toda a infraestrutura: pipeline pronto, ambiente provisionado, observabilidade já ligada, segurança embutida. Ela reduz carga cognitiva — e esse é o teste para saber se o que você está construindo é mesmo plataforma.

Também é o investimento mais fácil de fazer cedo demais. Plataforma para três times custa mais do que economiza, e a versão que você construiria hoje não é a de que eles vão precisar.

O problema que ela resolve

Sem plataforma, cada time resolve os mesmos problemas do zero: como fazer deploy, como expor um serviço com TLS, onde ficam os segredos, como instrumentar, o que precisa para passar em auditoria. O resultado previsível é dez soluções diferentes, nenhuma completa, e uma superfície de segurança impossível de garantir.

A plataforma transforma isso em caminho pronto: o time descreve o que quer e recebe o resto, com os padrões da empresa já embutidos.

Sinais de que chegou a hora

Sinais reais, observáveis:

• Duplicação com divergência: cinco times têm pipeline próprio, e nenhum tem verificação de segurança completa.
• Fila de tickets para operações repetitivas: criar ambiente, liberar acesso, provisionar banco.
• Tempo até o primeiro deploy de um serviço novo medido em semanas.
• Padrão que não se propaga: uma boa prática existe em um time e não chega aos outros.
• Escala: acima de umas cinco a oito equipes de produto, a coordenação manual quebra.

E os sinais de que não é hora: menos de três times, produto ainda buscando encaixe, ninguém disponível para manter, ou a motivação sendo “as empresas grandes têm uma”.

O custo real de manter

Plataforma é um produto vivo. Some antes de decidir:

• Pessoas dedicadas — abaixo de três ou quatro, ela vira projeto paralelo de alguém e apodrece.
• Suporte a usuários internos, todos os dias.
• Compatibilidade: mudança de plataforma quebrando o serviço de outro time é o pecado capital, e evitar isso custa versionamento e migração assistida.
• Documentação que acompanha a realidade.
• Plantão próprio: se a plataforma cai, todos param.

Se você não pode pagar isso, a alternativa honesta é melhor do que uma plataforma abandonada: templates versionados e um repositório de referência bem cuidado, mantidos por um time habilitador.

Plataforma como produto, com usuários

O erro mais comum não é técnico. É construir a plataforma que o time de infraestrutura gostaria de usar, em vez da que os times de produto precisam. Sinais de que isso aconteceu: adoção baixa, times contornando o caminho oficial, e a plataforma sendo “obrigatória” por decreto.

Tratar como produto significa, na prática:

• Adoção é voluntária. Se o caminho é bom, ele vence sozinho. Obrigar esconde o problema em vez de resolvê-lo.
• Usuários têm nome. Converse com os times, observe alguém subindo um serviço, meça o atrito (DX).
• Existe roadmap e existe versão. Mudança quebrando tem aviso, prazo e migração.
• Existe métrica de sucesso: tempo até o primeiro deploy, percentual de serviços no caminho pavimentado, satisfação interna, tickets manuais eliminados.

Comece pequeno

O caminho que costuma funcionar não começa com portal nem com Backstage:

1. Identifique a coisa mais repetida com dor (subir serviço novo, provisionar banco).
2. Resolva-a bem, para um time piloto, com template e automação.
3. Documente e ofereça para o segundo time. Ajuste com o que ele reclamar.
4. Só depois de dois ou três caminhos maduros, pense em catálogo e portal.

Plataforma cresce por caminhos entregues, não por arquitetura desenhada. O primeiro caminho pavimentado é assunto da próxima página.

Próximo passo: construa o primeiro caminho em Golden paths.