Cemitério de startups de e-mail: por que a maioria das startups de e-mail fracassa
(forwardemail.net)Matriz de fracasso das startups de e-mail
- Muitas startups de e-mail eram apenas uma interface simples sobre infraestruturas já existentes, como Amazon SES ou Postfix
- Skiff, Sparrow, Email Copilot, ReplySend, Nveloped, Jumble e InboxFever fracassaram ou foram encerradas após aquisição
- A maioria das startups de e-mail formadas pela YC e pela Techstars fez pivot ou encerrou as atividades cedo
- Serviços que não conseguiram construir sua própria infraestrutura sobreviveram apenas no curto prazo
Checagem da realidade da infraestrutura
- A maioria das startups de e-mail desenvolve apenas apps ou clientes, sem construir servidores de fato
- As empresas bem-sucedidas oferecem API SMTP e infraestrutura de entrega, como SendGrid, Mailgun e Postmark
- Em vez de tentar mudar o protocolo, o padrão de sucesso é fortalecer o fluxo de trabalho existente
Por que a maioria das startups de e-mail fracassa
-
1. O protocolo funciona bem, mas a implementação é difícil
- SMTP, IMAP e POP3 foram validados ao longo de décadas
- O problema não é um novo protocolo, mas a qualidade da implementação
-
2. O efeito de rede é absoluto
- O e-mail é usado por mais de 4 bilhões de pessoas e é compatível com todas as plataformas
- O custo de substituição é alto, o que dificulta a migração para outro serviço
-
3. O alvo é o problema errado
- “E-mail é complicado”, “precisa de IA”, “a segurança é fraca” etc. são premissas equivocadas
- Os problemas realmente importantes são confiabilidade de entrega, filtragem de spam e ferramentas para desenvolvedores
-
4. A dívida técnica é grande
- Operar servidores SMTP, lidar com spam, grandes volumes de armazenamento e infraestrutura de autenticação e entrega é tudo muito difícil de construir
-
5. A infraestrutura já existe
- Há abundância de infraestrutura open source e comercial, como Amazon SES, Postfix, Dovecot e SpamAssassin
Estudo de casos de fracasso de startups de e-mail
-
Caso Skiff
- Posicionou-se como uma “plataforma de e-mail e produtividade com foco em privacidade” e atraiu investimentos consideráveis de venture capital
- Em fevereiro de 2024, a Notion adquiriu a Skiff, prometendo integração e continuidade no desenvolvimento
- Na prática, poucos meses após a aquisição, o serviço foi encerrado imediatamente, e os fundadores deixaram a Notion para se juntar à Cursor
- Milhares de usuários foram forçados a migrar de serviço
-
Análise por aceleradora
-
Y Combinator: fábrica de apps de e-mail
- Emailio (2014): cliente de e-mail mobile → pivot para wellness
- MailTime (2016): e-mail em formato de chat → pivot para serviço de analytics
- reMail (2009): busca de e-mail no iPhone → adquirida pelo Google e depois encerrada
- Rapportive (2012): perfis sociais no Gmail → adquirida pelo LinkedIn e depois encerrada
- Taxa de sucesso: houve alguns casos bem-sucedidos de aquisição (reMail, Rapportive), mas a maioria terminou em pivot ou acqui-hire
-
Techstars: cemitério de e-mail
- Email Copilot (2012): encerrada após aquisição
- ReplySend (2012): fracasso total
- Nveloped (2012): “Easy. Secure. Email” → fracasso
- Jumble (2015): serviço de criptografia de e-mail → fracasso
- InboxFever (2011): API de e-mail → fracasso
- Padrão: proposta de valor vaga, ausência de inovação técnica real e fracasso rápido
-
-
A armadilha do venture capital
- Paradoxo do financiamento por VC: startups de e-mail parecem simples, mas na prática são quase impossíveis
- A própria premissa que atrai investidores já é uma estrutura que garante o fracasso
- Realidade: a infraestrutura e os protocolos de e-mail já são robustos, e é impossível para uma nova startup substituí-los
A realidade técnica da stack moderna de e-mail
-
A maioria das startups de e-mail não constrói uma nova infraestrutura própria; em vez disso, adiciona aplicações cliente sobre servidores e protocolos de e-mail já existentes
-
Por causa disso, limitações básicas e problemas de desempenho se repetem continuamente, tornando-se um dos eixos do fracasso dessas startups
-
Uso excessivo de memória (Memory Bloat)
- Clientes de e-mail modernos são, em sua maioria, webapps baseados em Electron, consumindo RAM em excesso
- Mailspring: usa 500MB+ de memória mesmo com funções básicas de e-mail
- Nylas Mail: antes de ser encerrado, consumia 1GB+ de memória
- Postbox: ocupa 300MB+ até mesmo em estado ocioso
- Canary Mail: crashes frequentes devido a problemas de memória
- Thunderbird: há relatos de uso de até 90% da memória do sistema
- Crise de desempenho do Electron:
- Frameworks multiplataforma como Electron e React Native são convenientes para desenvolvedores, mas usam recursos de forma ineficiente
- Como resultado, surge a situação em que funções simples de e-mail consomem centenas de MB a vários GB de memória
-
Drenagem de bateria (Battery Drain)
- Devido a código e formas de operação ineficientes, o consumo de bateria em dispositivos móveis e notebooks é severo.
- Processos em background ficam sempre em execução
- Chamadas de API desnecessárias ocorrem a cada poucos segundos
- O gerenciamento de conexões é ineficiente
- Mesmo sem dependências de terceiros desnecessárias além das funções essenciais, o desperdício de recursos é grave
Padrões de aquisição: sucesso vs fracasso
-
Dois padrões
- Padrão de app cliente (a maioria fracassa)
- Aplicativos clientes de e-mail normalmente são encerrados rapidamente após a aquisição
- Eles prometem uma nova experiência de usuário, mas não conseguem superar a dependência de infraestrutura e a barreira do efeito de rede, tornando a manutenção inviável
- Padrão de infraestrutura (frequentemente bem-sucedido)
- Empresas que fornecem infraestrutura central de e-mail, como SMTP e APIs, continuam crescendo após aquisição ou são integradas a plataformas, gerando resultados sustentados
- Padrão de app cliente (a maioria fracassa)
-
Casos recentes
-
Fracasso de apps cliente
- Mailbox → Dropbox → Shutdown (2013–2015)
- Sparrow → Google → Shutdown (2012–2013)
- reMail → Google → Shutdown (2010–2011)
- Skiff → Notion → Shutdown (2024)
-
Sucesso excepcional
- Superhuman → Grammarly (2025)
- Caso de aquisição bem-sucedida por integração estratégica. Um exit bem-sucedido raro no setor de clientes de e-mail
- Superhuman → Grammarly (2025)
-
Sucesso em infraestrutura
- SendGrid → Twilio (2019): aquisição de US$ 3 bilhões, com crescimento contínuo depois disso
- Mailgun → Sinch (2021): integrada por meio de aquisição estratégica
- Postmark → ActiveCampaign (2022): contribuiu para expandir as funcionalidades da plataforma
-
- Apps cliente frequentemente terminam em encerramento após aquisição, enquanto empresas fornecedoras de infraestrutura tendem claramente a sobreviver e se tornar elementos centrais das plataformas mesmo depois de adquiridas
Evolução e consolidação da indústria
-
Desenvolvimento natural da indústria
- A indústria de e-mail evoluiu ao longo do tempo na forma de grandes empresas adquirindo pequenas companhias para integrar funcionalidades ou eliminar concorrência
- Isso não é necessariamente um fenômeno negativo, mas um processo natural de evolução visto na maioria das indústrias maduras
-
Mudanças após a aquisição
Quando uma empresa de e-mail é adquirida, as mudanças que os usuários enfrentam são as seguintes:- Migração de serviço: é preciso transferir contas e dados para a nova plataforma
- Mudanças de funcionalidade: recursos especializados podem desaparecer ou ser substituídos de outra forma
- Ajuste de preços: o modelo de assinatura e os planos podem mudar
- Incômodo durante a integração: podem ocorrer falhas ou interrupções temporárias durante o processo de integração do serviço
-
O que os usuários devem considerar em períodos de transição
Respostas possíveis dos usuários em períodos de consolidação do setor:- Avaliar serviços alternativos: buscar outros fornecedores com funcionalidades semelhantes
- Entender o caminho de migração: a maioria dos serviços oferece ferramentas de exportação, então vale usá-las
- Considerar a estabilidade de longo prazo: é mais vantajoso escolher fornecedores confiáveis e com histórico longo de operação
Checagem de realidade do Hacker News
Todas as startups de e-mail recebem repetidamente o mesmo feedback no Hacker News:
- "O e-mail já funciona bem, isso não resolve nenhum problema"
- "Basta usar Gmail/Outlook, que todo mundo já usa"
- "Mais um cliente de e-mail, vai encerrar as atividades em menos de 2 anos"
- "O problema real é spam, e isso não resolve isso"
Insight principal: a crítica da comunidade está correta. O motivo de as startups de e-mail receberem sempre as mesmas críticas é que os problemas fundamentais a serem resolvidos continuam sendo os mesmos
A febre moderna das startups de e-mail com IA
-
A onda mais recente
Em 2024, surgiu uma nova onda de startups de "e-mail com IA", e a primeira grande aquisição bem-sucedida já aconteceu:- Superhuman: levantou US$ 33 milhões no total, adquirida pela Grammarly em 2025 — uma rara aquisição de app cliente considerada caso de sucesso
- Shortwave: um wrapper sobre o Gmail que adiciona resumos com IA
- SaneBox: filtragem de e-mail com IA que realmente funciona, mas não é revolucionária
-
Os problemas continuam
Colocar o rótulo de "IA" não resolve os problemas fundamentais do e-mail:- Resumos com IA: a maioria dos e-mails já é curta e concisa
- Resposta inteligente: o Gmail já oferece isso há anos
- Agendamento de envio: o Outlook já oferece isso nativamente
- Detecção de prioridade: clientes de e-mail existentes já têm sistemas de filtragem eficazes
Realidade principal: recursos de IA não se tornam uma solução fundamental porque, na prática, exigem enormes investimentos em infraestrutura para resolver inconvenientes relativamente pequenos
Casos de e-mail que realmente deram certo
-
Empresas de infraestrutura (casos de sucesso)
- SendGrid: adquirida pela Twilio por US$ 3 bilhões
- Mailgun: mais de US$ 50 milhões em receita anual, adquirida pela Sinch
- Postmark: serviço lucrativo, adquirido pela ActiveCampaign
- Amazon SES: registra receita de bilhões de dólares
- Padrão: elas construíram infraestrutura, não apps
-
Provedores de serviço de e-mail (os sobreviventes)
- FastMail: mais de 25 anos de operação, empresa independente e lucrativa
- Controvérsia sobre o investimento em JMAP: a Fastmail investiu recursos no protocolo JMAP, cuja adoção continuou limitada por mais de 10 anos, enquanto ao mesmo tempo recusava a criptografia PGP pedida por muitos usuários. Isso é visto como uma escolha estratégica de priorizar inovação de protocolo em vez das demandas dos usuários. Ainda hoje, a maioria dos clientes de e-mail continua dependente de IMAP/SMTP
- ProtonMail: focada em privacidade, com crescimento sustentável
- Zoho Mail: operação estável como parte de uma grande suíte de produtos empresariais
- Forward Email (nós): mais de 7 anos de operação, alcançando lucratividade e crescimento ao mesmo tempo
- Caso de sucesso corporativo: a Forward Email oferece suporte à solução de e-mail de 30.000 ex-alunos da Universidade de Cambridge, gerando economia anual de US$ 87.000
- Padrão: elas não substituem o e-mail, e sim o fortalecem.
- FastMail: mais de 25 anos de operação, empresa independente e lucrativa
-
Caso excepcional de sucesso: Xobni
A Xobni foi uma startup rara que teve sucesso ao melhorar o ambiente de e-mail existente.- A estratégia correta:
- Construída sobre o e-mail existente: integração com o Outlook
- Resolveu problemas reais: gestão de contatos e busca em e-mails
- Foco em integração: funcionava de acordo com os fluxos de trabalho existentes
- Foco corporativo: mirando o mercado empresarial disposto a pagar por mais produtividade
- Resultado: em 2013, foi adquirida pelo Yahoo por US$ 60 milhões, gerando retorno relevante para os investidores.
- Trajetória posterior dos fundadores:
- Matt Brezina: investidor-anjo ativo, com investimentos em Dropbox, Mailbox e outras
- Adam Smith: continuou fundando empresas bem-sucedidas na área de produtividade
- Ambos os fundadores comprovam que "o sucesso no e-mail vem da melhoria, não da substituição"
- A estratégia correta:
-
Padrões de sucesso
Os pontos em comum entre as empresas bem-sucedidas no setor de e-mail:
Existe algum caso de reinvenção bem-sucedida do e-mail?
Essa pergunta aprofunda a essência da inovação no e-mail
A resposta curta é a seguinte: ninguém conseguiu substituir o e-mail com sucesso, mas há casos de sucesso em “fortalecê-lo”.
-
Inovações que realmente se consolidaram
Nos últimos 20 anos, as inovações que se firmaram no e-mail tiveram algo em comum: todas fortaleceram os protocolos existentes, em vez de substituí-los:- Encadeamento de conversas do Gmail: melhora na organização dos e-mails
- Integração de calendário do Outlook: reforço no gerenciamento de agenda
- Aplicativos de e-mail para celular: melhoria de acessibilidade e usabilidade
- DKIM / SPF / DMARC: reforço na autenticação e segurança de e-mail
- Padrão: toda inovação bem-sucedida complementa o e-mail, em vez de substituí-lo.
-
Ferramentas que complementam o e-mail, em vez de substituí-lo
- Slack: é uma ferramenta de chat para equipes, mas ainda envia notificações por e-mail
- Discord: é uma plataforma voltada para comunidades, mas o gerenciamento de conta continua baseado em e-mail
- WhatsApp: é otimizado para mensagens, mas as empresas continuam usando e-mail
- Zoom: é essencial para videoconferências, mas os convites de reunião são enviados por e-mail
-
O experimento HEY
O HEY, da Basecamp, foi recentemente a tentativa mais séria de “reinventar” o e-mail.- Lançamento: surgiu em 2020 com uma grande campanha de divulgação
- Abordagem: apresentou um novo paradigma de e-mail, com triagem, agrupamento e fluxos de trabalho
- Reação: alguns adoraram, mas a maioria continuou usando o e-mail tradicional
- Realidade: no fim, não passou de uma nova interface sobre um e-mail ainda baseado em SMTP/IMAP
- Caso empírico: o fundador DHH usa o Forward Email há anos em seu domínio pessoal
dhh.dk. Isso mostra que até inovadores do e-mail dependem de uma infraestrutura comprovada.
-
O que realmente funciona
As inovações de e-mail mais bem-sucedidas são as seguintes:- 1. Infraestrutura melhor: servidores mais rápidos, filtragem de spam aprimorada, melhor entregabilidade
- 2. Interfaces aprimoradas: visualização em conversas do Gmail, integração de calendário do Outlook
- 3. Ferramentas para desenvolvedores: APIs de envio de e-mail, webhooks para rastreamento
- 4. Fluxos de trabalho especializados: integração com CRM, automação de marketing, e-mails transacionais
Conclusão: até hoje, nenhuma inovação conseguiu substituir o e-mail; todas tiveram sucesso ao tornar o e-mail melhor
Construindo infraestrutura moderna para os protocolos de e-mail existentes: a nossa abordagem na Forward Email
Antes de falar dos casos de fracasso, é importante entender o que realmente funciona no e-mail
O problema não é que o e-mail em si esteja quebrado, e sim que muitas empresas tentam “consertar” um sistema que já funciona bem
-
O espectro da inovação em e-mail
A inovação em e-mail pode ser dividida, em linhas gerais, em três categorias:- 1. Aprimoramento de protocolos: implementar padrões como SMTP, IMAP e POP3 de forma mais estável e rápida
- 2. Melhoria de fluxo de trabalho: ferramentas e recursos que tornam mais eficiente o uso do e-mail existente
- 3. Inovação em UI/UX: reforço da acessibilidade e da usabilidade por meio de novas interfaces
-
Por que focamos em infraestrutura
Em vez de criar um novo aplicativo, escolhemos construir uma infraestrutura de e-mail moderna. Os motivos são os seguintes:- Protocolos de e-mail comprovados: o SMTP funciona de forma estável desde 1982
- O problema é a qualidade da implementação: muitos serviços de e-mail ainda usam stacks de software ultrapassadas
- O que os usuários querem = confiabilidade: não novos recursos, mas fluxos de trabalho estáveis que não quebrem
- Necessidades dos desenvolvedores: é preciso oferecer APIs e interfaces de administração melhores
-
O que realmente funciona no e-mail
O padrão de sucesso é simples: fortalecer os fluxos de trabalho de e-mail existentes, em vez de substituí-los- Construir servidores SMTP mais rápidos e confiáveis
- Melhorar a filtragem de spam sem atrapalhar e-mails legítimos
- Oferecer APIs amigáveis para desenvolvedores que aproveitem os protocolos existentes
- Melhorar a taxa de entrega com a infraestrutura correta
Conclusão: a inovação no e-mail não está em “substituir”, mas em melhorar o sistema existente por meio da infraestrutura
Nossa abordagem: por que a Forward Email é diferente
-
O que fazemos (What We Do)
- Construímos infraestrutura de verdade: desenvolvemos servidores SMTP/IMAP do zero
- Foco em confiabilidade: garantia de 99,99% de uptime e tratamento correto de erros
- Fortalecemos os fluxos de trabalho existentes: compatível com todos os clientes de e-mail e funcionamento estável
- Suporte para desenvolvedores: oferecemos APIs e ferramentas realmente utilizáveis
- Compatibilidade total: conformidade completa com os padrões SMTP / IMAP / POP3
-
O que não fazemos (What We Don’t Do)
- Desenvolver um novo cliente de e-mail em nome da “inovação”
- Tentar substituir os protocolos de e-mail existentes
- Adicionar recursos de IA desnecessários
- Fazer promessas fantasiosas de que vamos “consertar” o e-mail
O ponto central é aumentar a confiabilidade e a compatibilidade sobre protocolos já comprovados, com foco em infraestrutura que realmente funciona, e não em inovação só para parecer moderna.
Como construímos uma infraestrutura de e-mail que realmente funciona
-
Nossa abordagem anti-startup (Our Anti-Startup Approach)
Enquanto outras empresas queimavam milhões de dólares tentando reinventar o e-mail, nós simplesmente nos concentramos em construir uma infraestrutura confiável:- Sem pivô: mais de 7 anos dedicados exclusivamente à infraestrutura de e-mail
- Sem estratégia de aquisição: meta de operação de longo prazo, não de venda rápida
- Sem exagero sobre inovação: não “consertar” o e-mail, mas fazê-lo funcionar melhor
-
O que nos torna diferentes (What Makes Us Different)
- Conformidade com padrões governamentais: conforme a Section 889, com clientes institucionais como a Academia Naval dos EUA
- Suporte a OpenPGP + OpenWKD: oferece criptografia PGP que o Fastmail recusou, fornecendo recursos reais de criptografia que os usuários querem
- Diferenciação da stack tecnológica:
- Toda a stack desenvolvida em JavaScript (em contraste com o Postfix baseado em código C dos anos 1980)
- Sem necessidade de glue code com uma linguagem única
- Arquitetura web-native, com excelente manutenibilidade
- Sem dívida legada, com uma base de código moderna
- Privacy by Design:
- Não armazena e-mails em disco nem em banco de dados
- Não armazena metadados, logs nem endereços IP
- O encaminhamento é processado apenas em memória
- Detalhes de implementação de segurança e arquitetura divulgados por meio do whitepaper técnico e da documentação
-
Por que temos sucesso onde outros fracassam (Why We Succeed Where Others Fail)
- 1. Construímos infraestrutura, não um app: foco em servidores e protocolos
- 2. Fortalecer em vez de substituir: mantém compatibilidade com clientes de e-mail existentes
- 3. Rentabilidade própria: operação sustentável sem pressão de VC
- 4. Conhecimento técnico profundo: mais de 7 anos de experiência especializada em e-mail
- 5. Foco em desenvolvedores: fornece APIs e ferramentas que ajudam a resolver problemas reais
Os desafios de segurança da infraestrutura de e-mail
A segurança de e-mail é um desafio complexo enfrentado por todos os provedores de serviço.
Mais importante do que incidentes individuais é entender as considerações de segurança comuns que precisam ser resolvidas.
-
Considerações comuns de segurança (Common Security Considerations)
- Proteção de dados: proteger com segurança os dados e as comunicações dos usuários
- Controle de acesso: autenticação e gerenciamento de permissões
- Segurança da infraestrutura: defesa de servidores e bancos de dados
- Conformidade regulatória: atender a normas como GDPR e CCPA
- Aplicação de criptografia avançada: a política de segurança do Forward Email inclui:
- Criptografia de caixas de e-mail baseada em ChaCha20-Poly1305
- Criptografia completa de disco baseada em LUKS v2
- Criptografia aplicada em armazenamento, memória e transmissão
-
O valor da transparência (The Value of Transparency)
Quando ocorre um incidente de segurança, a resposta mais importante é transparência e ação rápida. As melhores práticas incluem:- Divulgação imediata: para que os usuários possam entender a situação e reagir
- Fornecer uma linha do tempo detalhada: mostrando a dimensão do problema e o nível de entendimento
- Correção rápida: demonstrando capacidade técnica
- Compartilhar aprendizados: contribuindo para melhorar a segurança de todo o setor
-
Desafios contínuos de segurança (Ongoing Security Challenges)
A segurança de e-mail continua evoluindo, e melhorias contínuas são necessárias em áreas como:- Padrões de criptografia: adoção de métodos modernos como TLS 1.3
- Protocolos de autenticação: fortalecimento de DKIM, SPF e DMARC
- Detecção de ameaças: aprimoramento da filtragem de spam e phishing
- Fortalecimento da infraestrutura: reforço da segurança de servidores e bancos de dados
- Gestão de reputação de domínio: criação de regras de bloqueio para responder a novas ameaças, como o caso de aumento de spam do Microsoft onmicrosoft.com
Conclusão: concentre-se em infraestrutura, não em apps
-
As evidências são claras (The Evidence Is Clear)
Após analisar centenas de startups de e-mail:- Taxa de fracasso de 80%+: a maioria das startups de e-mail fracassa completamente (o número real provavelmente é ainda maior)
- Apps clientes em sua maioria fracassam: aquisições acabam levando ao encerramento do serviço
- Infraestrutura tem chance de dar certo: empresas que constroem serviços SMTP/API frequentemente prosperam
- Pressão do capital de risco: financiamento de venture capital cria pressão de crescimento irrealista
- Acúmulo de dívida técnica: construir infraestrutura de e-mail é muito mais difícil do que parece
-
O contexto histórico (The Historical Context)
Nos últimos 20 anos, startups vêm prevendo repetidamente o fim do e-mail:- 2004: “as redes sociais vão substituir o e-mail”
- 2008: “as mensagens móveis vão matar o e-mail”
- 2012: “Slack vai substituir o e-mail”
- 2016: “a IA vai revolucionar o e-mail”
- 2020: “a era do trabalho remoto exige novas ferramentas de comunicação”
- 2024: “a IA finalmente vai consertar o e-mail”
Mas o e-mail continua existindo, crescendo e sendo essencial.
-
A verdadeira lição (The Real Lesson)
A lição não é que o e-mail não possa ser melhorado, mas sim que é preciso adotar a abordagem correta:- 1. Os protocolos de e-mail são válidos: SMTP, IMAP e POP3 são padrões comprovados
- 2. A infraestrutura é o essencial: confiabilidade e desempenho importam mais do que recursos chamativos
- 3. Fortalecer em vez de substituir: ofereça melhorias que funcionem junto com o e-mail, não contra ele
- 4. Sustentabilidade acima de crescimento: empresas lucrativas sobrevivem mais do que o modelo de VC de “crescer rápido e quebrar tudo”
- 5. Suporte a desenvolvedores: ferramentas e APIs para desenvolvedores geram mais valor do que apps para o usuário final
- Oportunidade principal: implementar melhor protocolos já comprovados, não criar novos protocolos
- Análise mais aprofundada: 79 Best Email Services (2025)
- Se você quer criar uma startup de e-mail, considere construir infraestrutura, não um app.
- O que o mundo precisa não é de mais apps de e-mail, mas de servidores de e-mail melhores
Cemitério ampliado do e-mail: mais fracassos e encerramentos de serviços
-
Os experimentos de e-mail do Google que deram errado (Google's Email Experiments Gone Wrong)
Apesar de ter o Gmail, o Google encerrou vários projetos de e-mail:- Google Wave (2009–2012): foi chamado de “matador do e-mail”, mas ninguém entendia
- Google Buzz (2010–2011): tentativa fracassada de integrar rede social e e-mail
- Inbox by Gmail (2014–2019): lançado como o sucessor “inteligente” do Gmail, mas acabou descontinuado
- Google+ (2011–2019): tentou integrar funções de e-mail, mas falhou
- Padrão: nem o Google, que já tem o Gmail, conseguiu reinventar o e-mail com sucesso
-
As três mortes do Newton Mail (The Serial Failure: Newton Mail's Three Deaths)
O Newton Mail morreu nada menos que três vezes:- 1. CloudMagic (2013–2016): cliente de e-mail inicial, adquirido pela Newton
- 2. Newton Mail (2016–2018): relançamento da marca, encerrado após o fracasso do modelo por assinatura
- 3. Newton Mail Revival (2019–2020): tentativa de retorno, falhou de novo
- Lição: clientes de e-mail não conseguem sustentar um modelo por assinatura
-
Os apps que nunca chegaram a ser lançados (The Apps That Never Launched)
Muitas startups de e-mail desaparecem antes do lançamento:- Tempo (2014): tentou integrar calendário e e-mail, mas foi encerrado antes do lançamento
- Mailstrom (2011): ferramenta de gestão de e-mails, adquirida antes do lançamento
- Fluent (2013): cliente de e-mail, desenvolvimento interrompido
-
O padrão aquisição-encerramento (The Acquisition-to-Shutdown Pattern)
Vários apps de e-mail são encerrados logo após serem adquiridos:- Sparrow → Google → Shutdown (2012–2013)
- reMail → Google → Shutdown (2010–2011)
- Mailbox → Dropbox → Shutdown (2013–2015)
- Accompli → Microsoft → Shutdown (absorvido pelo Outlook Mobile)
- Acompli → Microsoft → Integrated (caso raro de sucesso)
- Padrão: aquisição muitas vezes significa encerramento do serviço
-
Consolidação da infraestrutura de e-mail (Email Infrastructure Consolidation)
Mesmo na infraestrutura, consolidação e encerramentos são frequentes:- Postbox → eM Client (2024): o eM Client adquiriu o Postbox e o encerrou imediatamente
- ImprovMX: foi adquirido várias vezes, com repetição de problemas de privacidade, anúncios de aquisição e listagens de venda
- Queda na qualidade do serviço: muitos serviços pioram depois de serem adquiridos
Cemitério do e-mail open source: quando o “grátis” se torna insustentável
-
Nylas Mail → Mailspring: um fork fracassado
- Nylas Mail: era um cliente de e-mail open source, mas foi descontinuado em 2017 e tinha graves problemas de uso de memória
- Mailspring: segue mantido como fork da comunidade, mas esbarra em alto consumo de RAM e limites de manutenção
- Realidade: clientes de e-mail open source têm dificuldade para competir com apps nativos
-
Eudora: uma marcha de 18 anos rumo à morte
- 1988–2006: dominou como cliente de e-mail no Mac/Windows
- 2006: Qualcomm anuncia o fim do desenvolvimento
- 2007: tornou-se open source como "Eudora OSE"
- 2010: projeto completamente encerrado
- Lição: até clientes de e-mail bem-sucedidos acabam desaparecendo
-
FairEmail: morto pelas políticas do Google Play
- FairEmail: cliente de e-mail para Android focado em privacidade
- Google Play: removido por "violação de política"
- Realidade: apps de e-mail podem desaparecer da noite para o dia por causa de políticas de plataforma
-
O problema da manutenção (The Maintenance Problem)
Motivos pelos quais projetos de e-mail open source fracassam:- Complexidade: é difícil implementar corretamente os protocolos de e-mail
- Segurança: exige atualizações de segurança constantes
- Compatibilidade: precisa funcionar com todos os provedores de e-mail
- Falta de recursos: esgotamento (burnout) de desenvolvedores voluntários
Boom de startups de e-mail com IA: a história se repete sob o nome de "inteligência"
-
A atual corrida do ouro do e-mail com IA (2024)
- Superhuman: levantou $33M, adquirida pela Grammarly em 2025
- Shortwave: saída da Y Combinator, Gmail + recursos de resumo por IA
- SaneBox: filtragem de e-mail com IA, serviço realmente lucrativo
- Boomerang: agendamento e respostas automáticas com base em IA
- Mail-0/Zero: desenvolvendo outra interface de cliente de e-mail com IA
- Inbox Zero: assistente de e-mail com IA de código aberto, tentando automatizar a gestão de e-mails
-
Febre de captação
- Só em 2024, VCs investiram mais de $100M
- Promessa recorrente: "experiência de e-mail revolucionária"
- Problema recorrente: só se constrói em cima da infraestrutura existente
- Resultado recorrente: a maioria deve fracassar em até 3 anos
-
Por que vão fracassar de novo
- 1. A IA tenta resolver um "não problema" do e-mail – o e-mail já funciona bem
- 2. O Gmail já oferece recursos de IA – resposta inteligente, caixa prioritária, filtragem de spam
- 3. Preocupações com privacidade – a IA precisa ler todos os e-mails
- 4. Problema na estrutura de custos – o processamento por IA é caro, e e-mail é essencialmente um serviço de baixo custo
- 5. Efeitos de rede – não é possível derrubar a posição dominante de Gmail/Outlook
-
O resultado inevitável
- 2025: Superhuman → aquisição pela Grammarly (caso raro de sucesso)
- 2025–2026: a maioria das startups de e-mail com IA vai pivotar ou fechar
- 2027: algumas sobreviventes serão adquiridas, mas com resultados mistos
- 2028: pode surgir uma nova moda como "e-mail em blockchain"
O desastre da consolidação: quando os "sobreviventes" viram desastre
-
Consolidação em larga escala dos serviços de e-mail
A indústria de e-mail passou por uma rápida consolidação (consolidation)- ActiveCampaign → aquisição da Postmark (2022)
- Sinch → aquisição da Mailgun (2021)
- Twilio → aquisição da SendGrid (2019)
- ImprovMX: passou por várias aquisições, com preocupações de privacidade e casos de revenda
-
Outlook: o "sobrevivente" com problemas que não param
O Microsoft Outlook continua sendo dominante no setor, mas segue apresentando problemas- Vazamento de memória: usa vários GB de RAM, exigindo reinicializações frequentes
- Problemas de sincronização: e-mails somem e depois reaparecem
- Problemas de desempenho: inicialização lenta, travamentos frequentes
- Problemas de compatibilidade: conflitos com provedores de e-mail de terceiros
Caso real em campo: mesmo seguindo a implementação padrão de IMAP, o Outlook quebra com frequência
-
Problemas de infraestrutura da Postmark
Problemas ocorridos depois da aquisição pela ActiveCampaign- Expiração de certificado SSL: em setembro de 2024, cerca de 10 horas de indisponibilidade
- Recusa de usuários legítimos: caso de Marc Köhlbrugge
- Saída de desenvolvedores: @levelsio: "Amazon SES é a última esperança"
- Falha da MailGun: caso de 2 semanas sem conseguir enviar e-mails
-
Casos recentes de morte de clientes de e-mail (2024–2025)
- Postbox → eM Client: encerrado imediatamente após a aquisição, com migração forçada de usuários
- Canary Mail: apesar do apoio da Sequoia, explosão de reclamações de usuários
- Spark by Readdle: aumento nos relatos de queda de qualidade
- Mailbird: problemas de licença e confusão com assinaturas
- Airmail: código baseado no Sparrow, problemas contínuos de confiabilidade
-
Casos de encerramento de extensões/serviços de e-mail
- HubSpot Sidekick: descontinuado em 2016, substituído por "HubSpot Sales"
- Engage for Gmail: encerrado em junho de 2024, com migração forçada de usuários
-
Empresas de e-mail que realmente sobreviveram
- Mailmodo: saída da YC, campanhas de e-mail interativas, $2M levantados da Sequoia Surge
- Mixmax: total de $13.3M captados, segue operando como plataforma de engajamento de vendas
- Outreach.io: avaliação de $4.4B+, preparando IPO
- Apollo.io: avaliação de $1.6B em 2023, levantou uma Série D de $100M
- GMass: baseado em extensão do Gmail, caso bootstrap de sucesso com $140K/mês
- Streak CRM: CRM baseado no Gmail, operando de forma estável desde 2012
- ToutApp: adquirida com sucesso pela Marketo em 2017
- Bananatag: adquirida pela Staffbase em 2021, continua operando como "Staffbase Email"
-
Padrão central
- As empresas bem-sucedidas não substituíram o e-mail, e sim reforçaram (enhance) o fluxo de trabalho
- Criaram ferramentas que funcionam de forma colaborativa com a infraestrutura de e-mail existente
Conclusão
- Mais de 80% das startups de e-mail fracassam
- A abordagem centrada em aplicativo fracassa, a abordagem centrada em infraestrutura tem sucesso
- Principais lições:
- 1. O protocolo de e-mail já funciona bem
- 2. A estabilidade e o desempenho da infraestrutura são importantes
- 3. Reforçar é mais eficaz do que substituir
- 4. É necessário um modelo de negócios sustentável
- 5. Ferramentas e APIs para desenvolvedores são a chave do sucesso
6 comentários
Li só até a metade e pensei: será que não vai ter o caso do hey.com? E ele aparece logo em seguida no texto haha.
Parece que e-mail é um produto com possibilidades infinitas, mas ao mesmo tempo um mercado em que é difícil tirar a posição dos players já estabelecidos..
Depois de configurar, acabam registrando o servidor em todo tipo de lista de servidores de spam, então o trabalho vira ficar resolvendo isso. Quando o cliente entra em contato de repente dizendo que não está funcionando, na maioria das vezes é porque o servidor foi listado como spam.
Ainda é um produto pequeno demais para dizer se já deu certo ou fracassou,
mas estou usando com muita satisfação um cliente de Gmail chamado Mimestream.
https://mimestream.com/
É, de longe, o cliente de e-mail com o qual fiquei mais satisfeito entre todos os que já usei... comecei a usá-lo ainda na beta e agora já faz quase 5 anos.
Hmm... os links da seção "Checagem de realidade do Hacker News" estão todos estranhos. Pelo visto, desde o original eles já foram colocados com links errados.
Ah, é mesmo. Mesmo procurando a fonte original, está difícil de encontrar, então acho melhor simplesmente deixar como está.
Opiniões no Hacker News