Por que as empresas de telecomunicações não conseguem criar plataformas? Lições de décadas atrás!

Por Matheus Cofferri – Last Mile

As operadoras de telecomunicações passaram mais de duas décadas tentando construir plataformas, e quase todas as tentativas acabaram no mesmo destino. No papel, tinham tudo a favor. O cartão SIM, talvez o elemento de segurança mais distribuído do mundo, relacionamento direto de faturamento com bilhões de clientes, APIs de identidade e localização, além de um fluxo contínuo de dados de uso. Parecia algo impossível de dar errado. Ainda assim, uma após a outra, iniciativas como Joyn, RCS, WAC, Vodafone 360 e as lojas de aplicativos das operadoras foram lançadas com grande expectativa, mas não foram adiante.

A comparação com o Titanic ajuda a entender.

Era o maior navio da sua época, construído com o que havia de mais avançado em engenharia e tratado como invencível. O problema não foi falta de estrutura, recurso ou capacidade. Foi a incapacidade de reagir com velocidade. Icebergs se movem mais rápido que comitês. No telecom, quem ocupou esse espaço foram empresas como WhatsApp, Apple e Stripe. Menores, mais rápidas e com foco total no desenvolvedor, avançaram enquanto as operadoras ainda estruturavam suas iniciativas. O WhatsApp chegou a centenas de milhões de usuários antes de o RCS encontrar um caminho viável. A Apple lançou sua App Store com centenas de aplicativos enquanto a WAC ainda discutia especificações. A Stripe simplificou pagamentos com poucas linhas de código, enquanto no mundo telecom isso se transformava em documentos extensos e difíceis de implementar.

O resultado ficou evidente ao longo do tempo. Um histórico de projetos que nasceram grandes, com discurso forte, mas que nunca ganharam tração real. Não foi falta de recurso. As operadoras sempre tiveram escala, base e capacidade de investimento. O ponto está na forma de operar. A cultura construída ao longo dos anos valoriza estabilidade, controle e conformidade. Isso funciona bem para infraestrutura. Mas plataformas exigem outra lógica. Velocidade, simplicidade e abertura para quem desenvolve em cima delas.

No fim, o erro foi parecido com o do Titanic. Não faltou ambição, nem tamanho. O problema foi acreditar que isso garantiria o resultado. Enquanto isso, outros avançaram, ocuparam espaço e construíram negócios relevantes sobre as próprias redes que as operadoras já tinham.

Os Icebergs que Eles Atingiram

Os destroços das plataformas de telecomunicações não são abstratos. São concretos, conhecidos e seguem um padrão claro. Cada iniciativa foi apresentada como a próxima grande virada do setor, percorreu um caminho parecido e terminou pelos mesmos motivos.

Padrões e APIs.
As operadoras também tentaram avançar pelo caminho das APIs. ParlayX, GSMA OneAPI e diversos programas regionais prometiam acesso a funcionalidades como mensageria, localização e faturamento. No papel, eram soluções poderosas. Na prática, eram difíceis de usar, mal documentadas e cheias de restrições. Analistas já apontavam o contraste entre o entusiasmo com APIs de iOS e Android e a indiferença com as alternativas das operadoras. Muitos desenvolvedores descreviam a experiência como encontrar portas fechadas. O problema estava na cultura: tratar quem desenvolve como algo secundário, quando deveria ser central.

Lojas de aplicativos de operadoras.
Vodafone 360, Orange Appshop, Verizon V CAST, O2 Litmus. A lista é longa e pouco memorável. Todas surgiram com poucos aplicativos, incentivos limitados e sem escala global. Diante da escolha entre um ecossistema fragmentado ou uma plataforma unificada como a App Store da Apple, os desenvolvedores seguiram o usuário. Em poucos anos, a maioria dessas iniciativas foi descontinuada de forma silenciosa. Faltou efeito de rede. Sem escala relevante, não existe ecossistema.

A Wholesale Applications Community (WAC).
Criada em 2010 por um grupo de operadoras e fabricantes, a WAC nasceu com a proposta de unificar a distribuição de aplicativos. A ideia era simples: desenvolver uma vez e distribuir em várias operadoras. Na prática, virou um exercício de coordenação entre concorrentes com interesses diferentes. Um modelo difícil de sustentar. Em pouco tempo, o projeto perdeu força e acabou sendo descontinuado. O principal obstáculo foi a governança. Uma coalizão não substitui um dono claro de plataforma.

RCS e Joyn.
O RCS foi concebido como a evolução do SMS, trazendo recursos como mensagens em grupo, confirmação de leitura e envio de mídia. A GSMA tentou consolidar o movimento com o Joyn. O problema foi o ritmo. Anos após as primeiras especificações, a implementação ainda era limitada e inconsistente. Enquanto isso, soluções como o WhatsApp já entregavam a mesma proposta com melhor experiência e escala global. Pesquisas da época já mostravam baixa confiança das próprias operadoras na capacidade do RCS competir. A limitação não estava na tecnologia, mas na execução.

O padrão se repete em todos os casos. Não faltou investimento, nem ambição, nem base instalada. Faltou velocidade, simplicidade e alinhamento com quem realmente constrói valor dentro de uma plataforma.

O setor tentou resolver um problema novo com uma lógica antiga. E pagou o preço por isso.

O cemitério de plataformas das operadoras de telecomunicações: uma década de grandes lançamentos afundados pelos mesmos icebergs: implantações lentas, padrões fragmentados e zero consideração pelos desenvolvedores.

Em todos esses fracassos, o padrão é inconfundível:  especificações excessivamente complexas, execução deficiente, governança fragmentada e falta de empatia com os desenvolvedores. As empresas de telecomunicações pensaram em termos de comitês e padrões, enquanto os verdadeiros construtores de plataformas pensaram em termos de velocidade, simplicidade e ecossistemas.

Por que as gigantes da tecnologia saíram na frente?

Se as empresas de telecomunicações eram o Titanic, as empresas de tecnologia eram os botes salva-vidas. Elas não eram maiores, não tinham mais recursos, mas entendiam o que faz uma plataforma funcionar: velocidade, simplicidade e ecossistemas.

Considere a App Store da Apple . Em 2008, a Apple lançou a loja com apenas 500 aplicativos. O que importava não era a quantidade, mas a experiência: um SDK único, um canal de distribuição unificado e um modelo econômico claro (divisão de 70/30). Os desenvolvedores acorreram em massa porque as regras eram simples, o público era enorme e as ferramentas eram refinadas. Em 2012, a App Store ultrapassou 30 bilhões de downloads, uma escala que nenhuma loja de operadora de celular poderia sequer sonhar. A Apple não perdeu anos elaborando padrões; ela lançou o produto, fez iterações e deixou que os efeitos de rede cuidassem do resto.

A Meta (Facebook) seguiu a mesma estratégia com sua plataforma de desenvolvedores. Em 2007, o Facebook abriu seu gráfico social para aplicativos externos. Em um ano, dezenas de milhares de desenvolvedores já haviam criado jogos e serviços sobre a plataforma, desde FarmVille até integrações com o Spotify. A Meta não criou um órgão de padronização. Ela publicou APIs, documentou-as minuciosamente e forneceu aos desenvolvedores acesso instantâneo a uma base global de usuários. A proposta era clara: desenvolver para o Facebook e obter viralização. Essa clareza jamais existiu nas iniciativas de telecomunicações, onde os desenvolvedores eram solicitados a analisar milhares de páginas de especificações sem nenhuma garantia de distribuição.

A Stripe talvez seja o contraponto mais claro à ParlayX e à OneAPI. Enquanto as empresas de telecomunicações ofereciam interfaces SOAP complexas e burocráticas, a Stripe reduzia os pagamentos a duas linhas de código. Seus fundadores eram notoriamente obcecados pelo “tempo até a primeira transação”, ou seja, a rapidez com que um desenvolvedor conseguia movimentar dinheiro pelo sistema. Esse foco absoluto na satisfação do desenvolvedor transformou uma pequena startup em uma empresa de US$ 100 bilhões. As empresas de telecomunicações, por outro lado, muitas vezes tratavam os desenvolvedores como cidadãos de segunda classe, que deveriam se adaptar à cobrança, à identidade e ao controle das operadoras. Não surpreendentemente, os desenvolvedores demonstraram sua insatisfação com suas decisões.

Razões por que Stripe Cancela Contas e Como Evitarlo | Prana Americano

O DNA cultural não poderia ser mais diferente. As empresas de telecomunicações equiparavam controle a valor. As empresas de tecnologia equiparavam adoção a valor. As empresas de telecomunicações tentavam controlar todas as camadas da infraestrutura; as empresas de tecnologia se concentravam em tornar uma parte irresistível e deixavam o ecossistema crescer ao seu redor. As empresas de telecomunicações pensavam em termos de comitês e conformidade. As empresas de tecnologia pensavam em termos de entrega e escalabilidade.

A ironia é que as empresas de telecomunicações possuíam ativos que a Apple, a Meta e a Stripe não tinham: identidade segura (o SIM), alcance global, contratos de faturamento recorrente e confiança das autoridades regulatórias locais. No entanto, faltava-lhes um elemento crucial para o sucesso de uma plataforma: uma mentalidade que prioriza os desenvolvedores e a velocidade em detrimento da perfeição. Enquanto as operadoras debatiam a interoperabilidade, as gigantes da tecnologia construíam ecossistemas irresistíveis. Quando os navios deixaram o porto, os botes salva-vidas já haviam cruzado o oceano.

O Problema do DNA

O que torna o histórico de falhas das empresas de telecomunicações tão consistente é que não se trata de uma questão circunstancial, mas sim estrutural. As operadoras de telecomunicações são moldadas por suas origens como serviços públicos regulamentados. Seus instintos são a conformidade, a estabilidade e a previsibilidade. Essa cultura é perfeita para administrar a infraestrutura nacional, mas prejudicial para negócios de plataforma que exigem velocidade, experimentação e tolerância ao risco.

As iniciativas de telecomunicações também seguem uma sequência recorrente: primeiro vem o padrão, seguido pelo produto. O RCS consistia em milhares de páginas de especificações IMS antes que alguém pudesse baixar um aplicativo. O OneAPI e o ParlayX eram documentos de comitê antes que os desenvolvedores vissem o código. A indústria tratava o consenso teórico como a base da inovação. Em contraste, a Apple lançou primeiro a App Store e permitiu que os padrões evoluíssem por meio da adoção. As plataformas prosperam com a demanda do produto, não com a imposição de padrões.

A fragmentação agravou o problema. Cada operadora tinha sua própria loja de aplicativos, cobrava suas próprias APIs e dava sua própria marca aos seus serviços. Os desenvolvedores se deparavam com uma colcha de retalhos de pequenos mercados em vez de um único público global. Isso é o oposto do que torna uma plataforma atraente. E mesmo onde as iniciativas eram nominalmente unificadas, como WAC ou RCS, as variações nacionais e as implementações opcionais destruíram a premissa de escalabilidade.

Por trás disso, havia uma profunda tendência ao controle. As operadoras equiparavam o controle de acesso à monetização, incluindo ecossistemas fechados, fluxos de faturamento proprietários e parcerias exclusivas. Mas os desenvolvedores querem vias livres, não fortalezas. A Apple e a Stripe impuseram regras suficientes para manter a ordem e, em seguida, recuaram. As empresas de telecomunicações nunca aprenderam esse equilíbrio.

Mesmo quando as plataformas mostravam potencial, eram sufocadas pela lógica do ARPU (receita média por usuário). Os executivos avaliavam cada iniciativa com base em seu impacto imediato na receita média por usuário. No entanto, as plataformas monetizam por meio de escala e ecossistemas, que raramente se alinham com os KPIs trimestrais. Pomares eram arrancados porque não davam frutos no primeiro ano.

Por fim, a própria governança ficou paralisada. Quase todas as principais iniciativas de plataforma eram projetos de consórcios ou da GSMA. Esperava-se que dezenas de operadoras, cada uma com agendas concorrentes, se alinhassem em relação aos roteiros técnicos. O WAC entrou em colapso sob esse peso. O RCS estagnou porque ninguém conseguia impor uma adoção consistente. As plataformas não podem esperar por consenso. Quando as operadoras finalmente chegaram a um acordo, o mercado já havia evoluído.

Em outras palavras, as empresas de telecomunicações não se depararam com icebergs por acaso. Elas navegaram com um casco construído para outro oceano.

Devemos ser botes Salva-vidas, Não Titanics!

Se toda essa trajetória ensina alguma coisa, é que as empresas de telecom não vão vencer Apple ou Stripe jogando o mesmo jogo. Insistir em construir mais uma grande plataforma, nos mesmos moldes, leva ao mesmo resultado. O caminho mais inteligente está em trabalhar com estruturas menores, mais abertas e alinhadas com aquilo que o setor realmente controla.

O primeiro ponto passa pelas plataformas voltadas ao B2B e a verticais específicas. No consumo massivo, a disputa já está consolidada. Mas em segmentos como logística, energia, defesa e saúde, existe um espaço claro. As empresas de telecom operam ativos relevantes nesses ambientes, como espectro, infraestrutura de baixa latência e relação com o regulador. Uma API que assegura identidade de dispositivos, qualidade de rede ou cobrança confiável pode ser muito mais valiosa para uma operação industrial do que qualquer nova tentativa de competir no mercado de apps.

O segundo ponto está nas APIs de rede. As operadoras possuem capacidades únicas como localização, autenticação, qualidade de serviço, faturamento e agora computação de borda. O problema nunca foi falta de recurso, mas a forma como isso é exposto. Enquanto isso continuar preso a especificações complexas e difíceis de implementar, a adoção seguirá limitada. Se essas capacidades forem entregues de forma simples, padronizada e com foco no desenvolvedor, o interesse aparece. A diferença está na execução. Oferta clara, modelo comercial consistente e experiência de uso direta.

O terceiro eixo é identidade e confiança. O SIM continua sendo um dos elementos de segurança mais distribuídos do mundo. E isso ganha ainda mais relevância em um ambiente com crescimento de automação, IoT e interações entre máquinas. A confiança tende a se tornar um dos principais ativos da economia digital. Existe aqui uma oportunidade concreta de posicionamento, transformando essa base instalada em uma camada de identidade confiável para serviços digitais.

No fim das contas, a IA aplicada à rede abre uma janela clara para sair do padrão que se repetiu por anos. Quando a rede ganha capacidade de decisão, com inferência distribuída, modelos rodando na borda, inteligência nas estações base e roteamento adaptativo para um volume crescente de dispositivos, o que está sendo entregue deixa de ser apenas conectividade. Surge uma camada de inteligência que pode ser monetizada. Isso muda o papel das empresas de telecom, que passam a sustentar aplicações e decisões, não apenas transportar dados. Mas isso só ganha tração quando é disponibilizado de forma utilizável, como componentes acessíveis, e não como estruturas fechadas e difíceis de integrar.

A principal mudança de direção está em abandonar a lógica de grandes construções centralizadas. Esse modelo já mostrou suas limitações. O espaço que se abre agora é outro: soluções menores, mais abertas e que se conectam naturalmente ao que outras empresas já estão construindo. O valor está em viabilizar, não em tentar concentrar.

Se houver um ajuste de foco, saindo do controle excessivo para colaboração, da complexidade para simplicidade e da lógica isolada para integração em ecossistemas, ainda existe muito espaço para evolução. O próximo ciclo não será marcado por uma grande plataforma dominante criada por telecom. Ele será sustentado por uma base confiável, distribuída e inteligente, que opera nos bastidores e viabiliza tudo o que acontece acima dela.

Baseado em um artigo publicado de SB no Substack, com adaptações.

Assine agora

Visão estratégica sobre o mercado de telecom e tecnologia, construída a partir do que realmente acontece no setor.

Ao me inscrever, concordo com os Termos de Uso do Substack e reconheço o Aviso de Coleta de Informações e a Política de Privacidade.