Ask HN: Alguém vive de uma API paga?

• Pergunta sobre se existem desenvolvedores solo ou pequenas equipes que conseguem se sustentar vendendo acesso a APIs
  • Que API é essa? Qual é o MRR? Como é o modelo de preços? Como vocês encontraram o primeiro cliente pagante?
• E, mais importante, que problema vocês estão resolvendo pelo qual as pessoas realmente estejam dispostas a pagar todo mês?
• Além disso, gostaria de ouvir sobre a maior dificuldade (limites de uso? suporte ao cliente? concorrência?) e também conselhos do tipo "eu gostaria de ter sabido disso antes de começar"

---

Casos de sucesso de APIs pagas

• APIs de OCR/extração de documentos e autenticação (CIAM): FormX(https://formx.ai), Authgear(https://authgear.com)

  • Cobrança por uso e contratos anuais, com MRR na faixa de US$ 35 mil a US$ 55 mil
  • Os primeiros clientes B2B vieram por parcerias com GCP/Azure e ISVs; depois disso, marketing virou o maior desafio
  • Houve dificuldades com suporte para desenvolvedores (resolver problemas e fazer troubleshooting com devs de outras equipes)

• API de screenshots: ScreenshotOne(https://screenshotone.com)

  • Desenvolvida por uma única pessoa, com MRR de US$ 20 mil e custo de servidores de US$ 5.500 por mês
  • Ampliação da base de usuários via SEO, redes sociais e marketing direto
  • Entrar nesse mercado é muito difícil e, se recomeçasse, escolheria um nicho mais fácil
  • Garante qualidade operando diretamente um cluster de navegadores, com extensões customizadas (remoção de anúncios/banners de cookies etc.)

• API de telecomunicações/SMS: 46elks

  • Integração direta com operadoras móveis locais na Suécia/Europa, em uma plataforma customizada baseada em Python
  • MRR de 500 mil euros, com cobrança baseada em uso
  • Os primeiros clientes vieram de networking offline, como hackathons e meetups; escalar é o desafio
  • Há grandes concorrentes globais, com destaque para a Twilio, e a diferenciação vem de localização e suporte

• API de machine learning (ML):

  • APIs de machine learning especializadas em domínios específicos, com cobrança por uso/volume
  • MRR de alguns milhares a algumas dezenas de milhares de dólares
  • A estrutura faz com que empresas de frontend fiquem com a maior parte da receita; só uma API de ML tem limites claros

• API de reconhecimento de fala (Speech-to-Text): borgcloud.org

  • Cobrança por hora (US$ 0,06/h), MRR de cerca de US$ 5.000
  • Os primeiros clientes pagantes chegaram por comunidades como o Reddit
  • A concorrência de preço com grandes nuvens (Whisper, Groq etc.) está se intensificando
  • Redução de custos com uso de uma rede própria de GPUs

Desafios e aprendizados em comum

• Marketing e suporte ao cliente são desafios maiores do que a tecnologia
  • Mesmo quando o público é formado por desenvolvedores, vendas ativas e suporte continuam sendo necessários
  • São usados vários caminhos, como GCP/Azure, hackathons, blogs e respostas no Stack Overflow
• É preciso cuidar de competitividade de preço, diferenciais e até questões legais
  • Quando você oferece apenas a API, a estrutura de receita tende a ser menos favorável do que a de empresas de frontend
  • Também é preciso considerar custos operacionais próprios (como servidores) e taxas de plataformas como a RapidAPI

Estrutura do mercado e estratégias de sobrevivência

• Negócios de API dão resultado em nichos fortes (problema/cliente/domínio específico)
  • Casos como ImageMagick, SMS, autenticação e parsing de receitas mostram que clientes pagam quando a solução elimina incômodos e ineficiências frente a open source ou grandes empresas
  • Outra saída é empacotar junto o frontend ou, ao oferecer só a API, alcançar clientes indiretamente por meio de vários apps
• O ponto central é resolver a 'dor real (pain point)' do cliente
  • Há mais valor no ponto de contato direto com o cliente (frontend), e os limites de receita de uma API sozinha são evidentes

Insights adicionais

• A maioria das respostas enfatiza em comum que "começar é difícil, mas é possível se você operar com consistência", que é preciso tomar cuidado com o aumento da concorrência e o surgimento de substitutos, e que só fornecer a API captura apenas parte do valor total do mercado
• Um negócio de API só tem sucesso quando o problema a ser resolvido é realmente claro e o cliente está disposto a pagar

[unqocn]

Que legal...! Parece que daria uma sensação de liberdade, mas ao mesmo tempo acho que deve ser difícil ter de ficar pensando o tempo todo na sustentabilidade disso.

[GN⁺]

Opinião do Hacker News

• Compartilhamento de experiência: começou como uma empresa de desenvolvimento sob encomenda e, com base na demanda dos clientes, acabou criando dois produtos de API. O primeiro é um serviço de OCR e extração de documentos; no início, como não havia uma solução útil que suportasse caracteres chineses, foi construído internamente. Mais recentemente, a direção mudou para adicionar várias funcionalidades usando LLMs/VLMs (com fine-tuning). Por exemplo, oferecem recursos como fine-tuning com dados de clientes específicos, ajuste de prompts para elementos específicos como caixas de seleção e divisão de PDFs de centenas de páginas em vários documentos menores. Atualmente, cerca de US$ 55 mil de MRR, com cobrança por página e contratos anuais (com muitos descontos). O segundo é um CIAM open source, com cerca de US$ 35 mil de MRR. Começaram sem saber nada de marketing e, no início, conseguiram os primeiros clientes pagantes colaborando como ISV com parceiros locais da GCP/Azure, entrando assim naturalmente no mercado “enterprise”. Destacam que marketing de produto é importante, mas suporte ao cliente para desenvolvedores também não é fácil — por serem desenvolvedores, conseguem dar suporte a desenvolvedores, mas às vezes acabam depurando problemas de outras equipes. Compartilham um caso real: após várias trocas de e-mail com um cliente dizendo que os resultados da API de repente estavam errados, pediram uma videoconferência com compartilhamento de tela e descobriram que a causa era que o cliente estava chamando a API com cache ativado no proxy. Links dos serviços FormX.AI e Authgear

  • Curiosidade sobre como surgiu a parceria com GCP/Azure locais e quais foram as boas práticas; pergunta se essa abordagem é inteligente, se grandes vendors de nuvem recebem bem esse tipo de proposta e se a ideia foi oferecer soluções customizadas para fechar negócios

• Introdução de um caso peculiar vivido por um conhecido. Em uma empresa de energia, consultores terceirizados tornaram o TI interno complexo, e os funcionários fixos, ineficientes, mal conseguiam rodar uma consulta. Essa pessoa conhecia bem o banco de dados de clientes de gás, abriu a própria empresa e passou de funcionário a consultor. Criou um pequeno caos na empresa, depois reapareceu propondo um contrato para migrar os dados dos clientes para o próprio sistema, gerenciá-los ali, aumentar a eficiência operacional com automação e lucrar com tarifa de uso da API + mensalidade

  • Opinião de que mover os dados de clientes de gás para o próprio sistema parece algo legalmente problemático

  • Impressão de que é uma entrada parecida com a dos consultores terceirizados já existentes, mas com um processo muito mais automatizado e eficiente

  • Soa como coerção ou extorsão com uma etapa extra, mas há curiosidade sobre se existe uma forma mais positiva de interpretar isso

  • Dúvida sobre se esse tipo de prática é legal e sobre quão comum é alguém que conhece muito bem a empresa sair para fazer esse tipo de trabalho de forma independente

• Apresentação do ScreenshotOne, negócio de API de screenshots tocado sozinho pelo amigo Dmytro, que recentemente passou de US$ 20 mil de MRR. Links para o X do Dmytro e para o serviço

  • Pergunta se ele gerencia diretamente os navegadores automatizados; especulação de que pode ser um wrapper de serviços como Scrapfly, Scraping Bee ou Zen Rows, e que talvez haja JS customizado para remover banners

  • Curiosidade sobre como empresas como a ScreenshotOne constroem sua base de usuários; pedido de ideias ou suposições

• Trabalha em uma empresa pequena, e a maior parte da receita total vem de uma API paga. Por confidencialidade, não pode revelar detalhes. A API é um modelo de machine learning de altíssimo nível para um cenário específico, com tabela pública de preços e sistema de descontos negociados individualmente. O maior desafio recente é que alternativas gratuitas “boas o suficiente”, como o Google Lens, estão canibalizando a demanda entre potenciais clientes gerais. Há arrependimento por terem feito apenas a API de ML e não um app próprio; compartilha que, na prática, quem implementa o frontend acaba ganhando mais dinheiro

  • Pedido de explicação sobre por que quem faz o frontend é quem acaba ganhando dinheiro

  • Opinião de que quem constrói o frontend resolve diretamente o problema do usuário final (a fonte da receita), enquanto a API fica um passo mais distante do faturamento

  • Curiosidade sobre se operar só a API de ML, em vez de um app para usuário final, é realmente tão lamentável assim; se vários apps usam a API, talvez focar na competência central e somar várias receitas menores ainda seja algo significativo

  • Análise de que, nesses casos, talvez o mercado da própria API fosse pequeno demais. Se a API praticamente corresponde a um único app, então faria sentido criar o app; mas, se mesmo atendendo vários apps a receita não foi suficiente, talvez a necessidade do mercado em si fosse limitada

• Opera uma API que converte receitas culinárias (frases de ingredientes, por exemplo: 2 cups finely chopped onions) em JSON estruturado e ganha cerca de US$ 200 por mês. Está em modo de manutenção desde 2019 e é gerida de forma extremamente passiva (uma ou duas horas por ano). Surpreende que os clientes ainda não tenham migrado totalmente para LLMs; provavelmente, em um nicho assim, a API existente ainda é competitiva por preço ou precisão. Seria bom se alguém comprasse e evoluísse o negócio, mas só preparar a venda levaria umas 30 a 40 horas, o que dá um custo de oportunidade de US$ 5 mil a US$ 10 mil; parece improvável que alguém pague isso por uma API que rende US$ 200 por mês. Ressalta que ter usado o RapidAPI no começo foi um grande erro (20% de taxa, UI ruim, inadimplência) e que teria sido melhor construir o próprio sistema de cobrança com Paddle. Link para ZestfulData

  • Compartilha a experiência de ter recriado o mesmo site com a API do ChatGPT como projeto de preparação para entrevistas; a maior dificuldade foi que, ao pedir ao ChatGPT exemplos de uso da API, os exemplos estavam desatualizados por causa da data do treinamento e não funcionavam

  • Diz que, no país onde mora, o custo de trabalhar como freelancer gira em torno de 200 euros por mês, em grande parte por causa de custos não salariais como seguro de saúde. Ou seja, com apenas US$ 200 de receita mensal isso seria inviável, e pergunta como alguém opera legalmente com uma margem tão baixa

  • Curiosidade sobre quem são os clientes dessa API; compartilha uma preocupação de marketing: teve várias ideias parecidas, mas imagina que, no fim, desenvolvedores que constroem suas próprias ferramentas talvez não queiram usar uma API externa para isso

  • Pergunta direta sobre como os primeiros clientes foram encontrados

• Também tem muito interesse em formas de gerar valor por meio de projetos técnicos. Mas observa que, ao explorar esse tema, há um problema: pessoas bem-sucedidas têm pouco incentivo para compartilhar detalhes da própria experiência. No pior caso, isso pode até convidar concorrentes a entrar. Diferentemente de comunidades abertas ao crescimento, como no open source, a cultura em negócios de API tende a ser menos compartilhadora porque é fácil copiar. Um tipo de serviço descoberto recentemente é o de transmissão automática de arquivos de vídeo longos, como lives no YouTube

  • Do ponto de vista técnico, é fácil cair na ilusão de que “qualquer um consegue construir isso”. No fim, o que importa é se os clientes realmente estão dispostos a pagar. Na era de ouro do Pirate Bay, música era praticamente grátis, mas o Spotify criou um mercado pago oferecendo conveniência superior. Há open source como o ImageMagick, mas ainda assim existem serviços bem-sucedidos em cima disso como API/SaaS. A razão é simples: pessoas e empresas pagam por “conveniência”. O ponto de partida é encontrar um problema que você conhece bem e que pode resolver com tecnologia, de preferência em um setor ou perfil de cliente pelo qual você tenha interesse real e conhecimento profundo. Como era desenvolvedor, acabou construindo uma API necessária para outros desenvolvedores

  • Toda empresa tem segredos conhecidos por poucos, e, ao conhecer profundamente um setor, dá para analisar o que os concorrentes estão fazendo. Mas o verdadeiro segredo para escalar um negócio está em um “know-how especial” que não aparece facilmente. A pessoa diz que, ainda hoje, conseguiria aplicar um novo twist a um negócio existente e gerar mais US$ 1 milhão por ano em até dois anos. Mas já trabalha mais de 60 horas por semana, ganha bem, e sente que o risco de vazar a análise ao compartilhar a ideia com terceiros para tocar esse negócio em conjunto é grande demais

• Vive de uma API de SMS e telefonia que criou. A receita recorrente mensal é de cerca de 500 mil euros, com cobrança baseada em uso (SMS/MMS por unidade, chamadas por minuto e número virtual com valor mensal). O núcleo da solução é conseguir acesso programático a redes móveis locais na Europa/Suécia para resolver problemas reais. Os primeiros clientes vieram de networking offline (hackathons, meetups, contatos pessoais etc.), mas esse método é também a maior dificuldade para escalar o negócio. Houve muitos momentos difíceis até chegar aqui, e até hoje parece irreal que tudo esteja funcionando tão bem

  • Curiosidade sobre a stack técnica usada; comentário de que conhece muita gente ligada à infraestrutura de TI da Suécia e por isso teria várias histórias relacionadas

  • Pergunta direta se isso pode ser entendido como um serviço parecido com o Twilio, mas para redes locais europeias

• Compartilhamento de experiência operando, com uma equipe de duas pessoas, uma API de fine-tuning de modelos de texto para imagem na dreamlook.ai. Quando lançaram, há três anos, o diferencial era treinar com TPU de forma mais barata e rápida, mas recentemente as GPUs alcançaram bastante e a concorrência open source ficou muito mais forte. Hoje a receita é de US$ 5 mil por mês; como já praticamente saíram da operação, esse valor ainda é aceitável, mas a receita caiu bastante em relação a um ano atrás. Os desafios não técnicos foram mais difíceis; gostavam de um produto centrado em tecnologia e insistiram em uma abordagem API-first, mas tiveram dificuldade com marketing, suporte comercial etc. Agora a pessoa voltou a trabalhar em uma grande empresa como desenvolvedor de ML e está satisfeita. Tem orgulho de ter construído um negócio próprio, mas hoje se sente mais feliz

  • Curiosidade sobre custos de operação com GPU e sobre se existem números concretos do orçamento usado na época da implementação

• Sobre encontrar clientes pagantes, há uma apresentação do Postman sobre plataforma de distribuição e rede para desenvolvedores e APIs (Postman Explore). A cobrança precisa ser feita por conta própria, mas a rede pode ajudar a ganhar visibilidade

• Compartilhamento do relato sobre como nasceu um negócio de API de podcasts, mencionando que é possível ler o caso do wenbin