- A Alchemy é o exemplo que a a16z usa para o quadrante "centralizado e sem token" da matriz de go-to-market em web3, operando como SaaS de nodes-as-a-service com assinatura por volume (a16z crypto).
- A porta de entrada é gratuita e medida: 30 milhões de compute units por mês, 25 requisições por segundo, 5 apps (Alchemy Pricing).
- O plano de uso paga US$ 0,45 por 1 milhão de CU até 300 milhões de CU mensais, e US$ 0,40 acima disso (Alchemy Pricing).
- Prova social ali é logo de cliente e uptime contratado, não gráfico de preço.
- A leitura da Kaleidos: infra web3 que vende para engenheiro compra confiança técnica antes de comprar narrativa, e token nesse contexto costuma atrapalhar mais do que ajudar.
O quadrante em que a Alchemy joga
A matriz de go-to-market da a16z crypto separa projetos por dois eixos: quão centralizada é a organização e se existe ou não um token no meio da relação com o usuário. No cruzamento "centralizado, sem token" ficam SaaS e marketplaces, e o exemplo citado é a Alchemy, descrita como uma plataforma que "fornece nodes-as-a-service" com tiers de assinatura baseados em armazenamento, dedicação e volume de requisições. A estratégia é apontada como uma combinação de product-led (freemium) e channel-led (a16z crypto).
Isso importa porque a discussão de marketing cripto quase sempre começa no lugar errado. A pergunta padrão é "qual a mecânica do incentivo", e o pressuposto escondido é que todo projeto de web3 precisa de um ativo para distribuir. A matriz da a16z desmonta esse pressuposto: quando o cliente é uma empresa que vai colocar sua aplicação em produção, o incentivo relevante não é token, é previsibilidade.
Quem vende infraestrutura não está disputando atenção de trader. Está disputando a decisão de um time de engenharia que precisa justificar internamente por que essa dependência não vai derrubar o produto às três da manhã.
A porta de entrada é gratuita, e é medida
O plano gratuito da Alchemy entrega 30 milhões de compute units por mês, 25 requisições por segundo, 5 apps e 5 webhooks, com acesso a todas as mainnets e testnets (Alchemy Pricing). Não há trial de 14 dias, não há cartão de crédito na frente, não há reunião obrigatória.
Repare no que a unidade de cobrança faz com a conversa comercial. A Alchemy não cobra por usuário nem por assento: cobra por compute unit, onde uma chamada JSON-RPC simples pode consumir 10 CU e operações mais complexas passam de 100 CU, com média observada de 27 CU por requisição (Alchemy Pricing). O preço acompanha o uso real da aplicação do cliente.
O efeito prático é que o custo do cliente cresce junto com o sucesso dele. Um desenvolvedor que está testando uma ideia num fim de semana nunca vê uma fatura. Quando o produto dele pega, a conta sobe, e ela sobe porque tem gente usando. Poucas conversas de renovação são mais fáceis do que essa.
Acima do gratuito, o plano de uso cobra US$ 0,45 por 1 milhão de CU nos primeiros 300 milhões de CU do mês e US$ 0,40 por 1 milhão de CU depois disso, com mínimo de 300 requisições por segundo, 30 apps e 100 webhooks, sem compromisso antecipado (Alchemy Pricing). No topo, o plano enterprise parte de 1.000 requisições por segundo, 200 apps, preço sob consulta, SLA assinado e suporte dedicado (Alchemy Pricing).
Três degraus, e cada um resolve um problema diferente: o primeiro remove o atrito de experimentar, o segundo remove o atrito de crescer, o terceiro remove o medo de depender.
Os dois botões dizem tudo sobre a operação
Voltando ao topo da página. "Get your API key" e "Talk to sales" convivendo no mesmo cabeçalho, com o gratuito reforçado no rodapé como "Get started for free" (Alchemy), não é indecisão de design. É a admissão de que existem dois compradores.
O primeiro é o desenvolvedor individual, que decide sozinho, testa em minutos e não fala com ninguém. O segundo é a empresa que precisa de contrato, de SLA e de alguém do outro lado do telefone. Um funil não atende os dois. Product-led sozinho trava quando o negócio precisa de garantia jurídica; sales-led sozinho é caro demais para atender quem ainda está brincando com uma ideia.
O ponto que quase todo projeto de infra erra é achar que precisa escolher. Não precisa. Precisa é deixar claro qual porta serve para quem, e não obrigar o desenvolvedor a passar pelo time comercial para ver o produto funcionar.
Vale uma pergunta honesta para quem está montando um GTM de infraestrutura agora: quanto tempo leva, no seu produto, entre alguém decidir testar e ver a primeira resposta da sua API? Se a resposta envolve preencher formulário e esperar retorno, o modelo é sales-led, e o custo de aquisição vai refletir isso.
A prova social é logo de cliente, não preço de token
A home lista nomes como Visa, Circle, Stripe, Robinhood, Polymarket, Uniswap, OpenSea e Chainlink (Alchemy). É o formato clássico de prova em B2B: se essas empresas confiaram a operação delas a essa camada, o risco percebido de você confiar cai.
Repare no que substitui o quê. Num projeto com token, a prova social costuma ser preço, TVL e número de holders, e todas essas métricas são voláteis, o que significa que a prova de hoje pode virar o constrangimento do trimestre que vem. Logo de cliente e uptime contratado envelhecem melhor.
Onde a leitura precisa de asterisco
A própria Alchemy destaca na home números como suporte a mais de 100 blockchains, 99,99% de uptime e mais de US$ 1 trilhão em transações por ano (Alchemy). São afirmações da empresa sobre a própria operação, publicadas em material de marketing, não auditoria independente. Elas contam como posicionamento, e o posicionamento é justamente o objeto deste estudo, mas não devem ser lidas como fato verificado por terceiro.
O mesmo asterisco vale para o resto da análise. O que está documentado publicamente é a estrutura de preço, a arquitetura de planos, os dois CTAs e o enquadramento que a a16z faz do modelo. A interpretação de por que isso funciona é leitura da Kaleidos a partir dessas peças públicas, não relato de dentro da empresa.
O que dá pra copiar de um projeto de infraestrutura
Quatro movimentos são replicáveis por qualquer projeto que venda ferramenta para quem constrói, com ou sem token no roadmap.
Primeiro: fazer a unidade de cobrança acompanhar o valor entregue. Cobrar por consumo real, e não por assento, alinha a fatura ao sucesso do cliente e remove a negociação anual sobre quantas licenças ficam paradas.
Segundo: tratar documentação como página de vendas. Em produto técnico, quem decide lê a doc antes de ler a landing. Doc confusa é objeção comercial disfarçada de problema de conteúdo.
Terceiro: separar as duas portas sem escondê-las. O gratuito não pode ser um labirinto até o formulário, e o enterprise não pode ser um segredo que só aparece depois do limite estourar.
Quarto: escolher a prova que envelhece bem. Estudo de caso com número de cliente real, status page pública e histórico de incidentes sustentam mais confiança do que qualquer campanha de lançamento.
E um movimento que não se copia: a lista de logos. Ela é resultado de anos de operação sem falha grave, não de campanha. Projeto novo que tenta simular esse tipo de prova antes de tê-la acaba com uma página de clientes cheia de parceria vaga, o que produz o efeito contrário.
Uma observação de método
Uma última observação de método. Este estudo olha estrutura de oferta e mensagem pública, que é o que qualquer concorrente também consegue observar. Números internos de receita, retenção e custo de aquisição da Alchemy não são públicos, e por isso não aparecem aqui.
A Kaleidos trabalha go-to-market de projetos cripto e fintech com esse mesmo critério: o que dá pra provar entra, o resto vira hipótese declarada. Se você está desenhando o GTM de uma infra e não sabe se o caminho é product-led, sales-led ou os dois, fale com a Kaleidos. Há mais análises de estratégia na seção de growth do blog.