Meu código de startup fracassada após 3 anos, agora aberto ao público

 (dylanhuang.com)
3 pontos por GN⁺ 2024-12-18 | 1 comentários | Compartilhar no WhatsApp
  • A Konfig começou como uma startup de ferramentas para desenvolvedores para facilitar integrações de API, mas encerrou as atividades três anos depois e publicou a codebase com o código do produto e materiais operacionais
  • O produto principal era um SDK Generator que criava bibliotecas cliente a partir de especificações OpenAPI, depois expandido para documentação e um ambiente interativo de testes de API
  • Houve alguma resposta de clientes startup, mas foi difícil transformar isso em um negócio de crescimento ultrarrápido por causa da dificuldade de fechar contratos e do baixo nível de preços
  • Depois, a empresa fez pivot para um produto de IA vertical B2B SaaS, mas mesmo com várias entrevistas e processos de vendas não encontrou tração de mercado suficiente para sustentar convicção de que seria um grande negócio
  • O repositório público foi aberto exatamente no estado em que estava no encerramento, sem limpeza nem revisão, incluindo código do produto, experimentos de pivot, scripts de vendas, configuração de deploy e site de marketing

Ferramentas de API para desenvolvedores que a Konfig estava construindo

  • A Konfig era uma startup de ferramentas de API para desenvolvedores iniciada no fim de 2022, focada em simplificar a forma como desenvolvedores trabalham com APIs
  • O objetivo era melhorar SDK generation, documentação e ferramentas ao redor de testes
  • O principal produto era o SDK Generator
    • Recebia especificações OpenAPI como entrada e gerava bibliotecas cliente para várias linguagens de programação
    • Depois foi expandido para uma ferramenta de documentação de API e um ambiente interativo de testes de API

Limites de crescimento e pivot para IA

  • Houve traction com alguns clientes startup, mas isso não levou a um negócio de crescimento ultrarrápido
  • Era difícil fechar contratos com potenciais clientes e, mesmo havendo ROI comprovável, a faixa de preço era baixa demais
  • Após os avanços da IA generativa, a empresa avaliou que poderia resolver problemas antes difíceis e fez pivot para um produto de IA vertical B2B SaaS
  • Foram conduzidas entrevistas com usuários e vendas em torno de várias ideias, mas não apareceu traction suficiente para dar convicção de que havia um caminho para um grande negócio

Repositório publicado exatamente como estava no encerramento

  • O repositório público é konfig-dev/konfig
  • O repositório foi publicado exatamente no estado em que estava quando a empresa encerrou as atividades
    • Sem limpeza
    • Sem polimento
    • Sem correções
    • A codebase mostra o estado real, sem filtros, do código de uma startup

Principais produtos criados ao longo de 3 anos

Código operacional e experimentos publicados junto

Reflexão deixada pelo fundador

  • Dylan Huang deixou o emprego em março de 2022 para se dedicar integralmente à startup e seguiu em frente mesmo sabendo da possibilidade de fracasso
  • Ele encara esse fracasso como uma experiência que lhe ensinou mais do que o sucesso teria ensinado
  • Como próximo passo, pretende explorar novas oportunidades, buscar uma posição adequada no mercado de trabalho e continuar aprendendo e crescendo
  • Também deixa aberta a possibilidade de voltar, um dia, a construir algo por conta própria

Leituras relacionadas

1 comentários

 
GN⁺ 2024-12-18
Comentários do Hacker News

  • Se o objetivo tivesse sido um pequeno negócio, em vez de um grande negócio com “crescimento ultrarrápido”, fico pensando em quantos ótimos produtos de nicho ainda existiriam hoje

    • É fácil falar isso, mas na prática é realmente difícil, porque você precisa aguentar 3 a 5 anos praticamente sem salário esperando alcançar um resultado parecido com o de uma empresa que recebeu investimento
      Para uma startup de 2 ou 3 pessoas sobreviver em um país desenvolvido, ela precisa vender uma quantidade enorme de licenças de 10 dólares por mês, e também é preciso considerar o custo de oportunidade
    • Se você vai captar investimento para cobrir os custos mensais necessários, do ponto de vista do investidor a conta do portfólio só fecha se houver potencial de crescimento ultrarrápido
      Se você mira desde o início um negócio pequeno e sustentável e dá certo, pode evitar investimento, mas se fez um pivô para uma direção totalmente nova no meio ou mais para o fim da trajetória da empresa, é bem provável que já tenha queimado a maior parte do caixa
    • Nesse caso, faria mais sentido arrumar emprego em uma empresa grande e receber uma recompensa parecida sem risco
    • Eu também tinha curiosidade sobre esse ponto. Sou um dos 3 cofundadores de uma empresa bootstrap de consultoria em uma região com baixo custo de vida, e há alguns anos pagamos 50 mil dólares por ano de salário para cada fundador; não demos uma sorte extraordinária nem tivemos uma capacidade de julgamento de negócios fora do comum, e ainda assim estamos indo muito bem
      Neste ano, a receita foi de 400 mil dólares, o lucro foi de 150 mil dólares e o crescimento foi de 40%, e a perspectiva comercial ficou muito melhor do que no começo do ano
      Esperamos um crescimento forte também no ano que vem, e estamos longe da saturação do mercado, então ainda há espaço para crescer por mais alguns anos
      Somando salário e 1/3 do lucro, isso dá 100 mil dólares neste ano para cada um, e com 40% de crescimento a empresa dobra a cada 2 anos. Se tudo der certo, só com salário e lucro já fica bem interessante, e ainda existe a possibilidade de uma venda em que os fundadores poderiam ganhar milhões de dólares
    • Dá para sentir um subtexto de “viu só, eu disse que era difícil!” aqui
      Tanto querer construir uma empresa como o Google quanto querer construir uma empresa como a Basecamp são caminhos válidos; são apenas tipos diferentes de empresa
      Na verdade, é fácil subestimar o risco de criar um “negócio de baixo risco”, e todo negócio é difícil. Palmas para a Konfig

  • Como cliente da Konfig, isso é realmente uma pena. Talvez tenhamos sido o primeiro cliente, e acho que até fomos mencionados em commits iniciais
    Dylan e Anh-Tuan resolveram muito bem vários problemas reais para nós. Eles ofereciam SDKs gerados e documentação/tutoriais hospedados e bem apresentados em um só lugar, e permitiam que os usuários chamassem nossa API para experimentar imediatamente com dados reais
    Antes da Konfig, escrevíamos manualmente SDKs improvisados que encapsulavam a API, e hospedávamos a documentação no ReadMe, mas aquilo não funcionava bem de forma interativa por causa das exigências de assinatura das requisições da nossa API
    Graças ao fato de a Konfig ter liberado isso como open source, agora hospedamos nossa documentação por conta própria: https://docs.snaptrade.com/
    Tenho muito respeito por essa equipe e gostaria que eles tivessem encontrado alguma forma de continuar
    Se você está operando um produto como a Konfig, que os clientes adoram mas cuja receita não cresce o suficiente, talvez valha a pena considerar aumentar mais os preços. Nós teríamos pago 2 a 3 vezes o que a Konfig cobrava, e teríamos pago ainda mais conforme crescêssemos, mas eles nem pediram isso e também não criaram cobrança por uso, como taxa mensal por SDK ou taxa mensal por demo

    • Conheci a Konfig por meio do seu produto. A documentação era tão boa que não tive como não investigar o que estava sendo usado por trás, e é realmente muito melhor do que Swagger ou Redoc
    • Fico curioso se vocês nunca chegaram a experimentar diretamente o https://github.com/OpenAPITools/openapi-generator
    • Se você quer uma alternativa leve para documentação de API, recomendo o Scalar. É simples, fácil de usar e muito melhor do que a documentação do Swagger

  • A cultura de startups nos EUA é realmente estranha. Nem tudo precisa escalar em velocidade máxima, e nem tudo precisa ser gigantesco
    Um negócio deveria focar mais em sustentabilidade, e não nesse modelo de pivotar três vezes em 2~3 anos e depois fechar as portas

    • Por um lado, isso faz sentido, mas por outro essa obsessão por “ou escala gigantesca ou fracasso” talvez seja justamente o que empurrou o ecossistema de startups dos EUA até onde está hoje, e uma das razões de ele estar muito à frente do resto do mundo
      Se você disser para muitos fundadores europeus de startup “daqui a 5 anos sua empresa vai estagnar em 15~20 funcionários, ter fluxo de caixa estável e pagar a você US$ 200 mil~250 mil por ano”, eles considerariam isso um grande sucesso. Nos EUA, especialmente se a empresa recebeu venture capital, isso pode ser visto como fracasso
      Já ouvi um investidor de venture capital do Vale do Silício dizer abertamente que, “se você considera vender a empresa por US$ 50 milhões um sucesso, então sua mentalidade está errada e eu não quero trabalhar com você”
      Se você não topar desafios grandes e riscos grandes, e se contentar com sucesso pequeno e crescimento estável, nunca vai ganhar o prêmio grande. Para o indivíduo isso pode ser mais saudável, mas para a economia como um todo pode ser pior
    • Pequenos negócios lucrativos, ou seja, empresas com equipes pequenas e objetivos de longo prazo que podem até parecer meio sem graça, provavelmente não chegam muito à primeira página do HN justamente porque não estabelecem metas irrealisticamente grandes
      É interessante como essa cultura abraça a mentalidade de “move fast and break things”, mas parece que isso se aplica principalmente ao setor de tecnologia. O mesmo vale para chamar um empresário que fracassou várias vezes de “empreendedor em série”; é difícil considerar um sucesso vender uma empresa insustentável
      É engraçado imaginar como soaria alguém que fracassou em vários esportes se chamando de “atleta em série”
    • O problema é que, no momento em que você recebe venture capital, é empurrado na direção da escala gigantesca
      Se você não recebe investimento, a não ser que consiga se financiar por conta própria com algo como consultoria, o caminho até se tornar autossustentável é muito mais difícil e demorado. O modelo aqui é a 37 Signals, mas eles são um caso extremamente excepcional por terem criado o Rails
      E mesmo depois de chegar a esse ponto, um concorrente financiado por VC pode entrar atropelando com conexões melhores e mais dinheiro
    • Estou na Europa e trabalho em uma empresa passando exatamente pelas mesmas dificuldades
      O ciclo de vendas B2B para grandes empresas é absurdamente longo, e a faixa de preço pela qual dá para vender para PMEs não é suficiente
      Mesmo quando entregamos valor e economizamos o tempo do cliente, explicar esse valor continua sendo sempre difícil
      A grama do vizinho sempre parece mais verde, mas também dá para entender por que as pessoas não querem ficar presas a um negócio B2B, repetindo o mesmo sofrimento por anos só para manter as luzes acesas, tendo conversas parecidas com clientes diferentes todo mês e explicando 10 vezes por ano por que aquilo tem valor. O burnout também pode chegar rápido
      Então eu também entendo a vontade de encontrar uma ideia de negócio em que o valor seja óbvio e as pessoas digam “leva meu dinheiro”
    • Há alguns fatores por trás da preferência das empresas ocidentais por expansão vertical, e não horizontal
      O primeiro é o retorno sobre o investimento. Se você vai captar o dinheiro dos outros, essas pessoas naturalmente esperam retorno, e um investidor inteligente diversifica o portfólio porque sabe que muitos investimentos vão falhar. Então ele pressiona todas as empresas investidas a crescer o máximo possível para compensar as perdas, fazendo com que algumas poucas empresas de altíssimo desempenho cubram os fracassos
      Esse crescimento vertical aparece não só em startups, mas também em grandes empresas. Acho que formalismo, excesso de regulação e burocracia pesam bastante nisso. Se você precisa passar por inúmeros procedimentos para licenças, impostos, configuração de contas de folha de pagamento etc., e se para abrir capital precisa enfrentar ainda mais etapas, então pode sair muito mais barato e ser menos arriscado ampliar o escopo de uma empresa já estabelecida do que separar e criar uma nova

  • Acho que éramos concorrentes. Sou o fundador da ReadMe.com, e nós oferecemos documentação de API, SDKs etc.
    Não sei exatamente por que tivemos sucesso, mas eu também passei por inúmeros começos errados e fui iterando aos poucos sobre a ideia central até chegar num ponto em que as pessoas ficavam visivelmente empolgadas
    Como eu sabia que esse mercado era difícil, investi muito tempo e esforço em coisas que não eram engenharia, e especialmente quando nos mostrávamos de forma mais sincera o Hacker News sempre foi favorável conosco
    Quero ouvir mais e vou tentar entrar em contato em privado
    No geral, parabéns por todo o esforço investido. Começar uma empresa e acreditar em si mesmo é algo incrivelmente difícil, e você pode se orgulhar disso

    • Talvez a razão de a ReadMe ter tido mais sucesso que a Konfig seja que ela começou 8 anos antes. A Konfig era uma boa ideia e foi bem executada, mas talvez simplesmente não fosse o momento certo
    • Já que estamos aqui, vale dizer que o efeito de transição em CSS da tela de login da ReadMe continua sendo um dos elementos de branding mais marcantes de que eu me lembro. Quem quer que tenha pensado nisso mandou muito bem

  • Acho que vamos ver muito esse tipo de resultado no futuro próximo. Quando a bolha da IA estourar, isso provavelmente vai se repetir

    • Eu acho que respeitaria mais o esforço se tivesse sido escrito assim
      “Vimos uma oportunidade de usar IA generativa em um produto SaaS B2B vertical para resolver um problema que antes não conseguíamos resolver. Criamos e propusemos várias ideias, mas a resposta dos usuários não foi positiva o bastante para nos dar confiança de que estávamos na direção certa para construir um grande negócio.”
      Do jeito que está no original, a primeira impressão é: “a pessoa que escreveu isso está tão mergulhada numa cultura passageira e de nicho que isso gera uma rejeição instintiva, e mesmo logo após um fracasso total ainda não conseguiu se desprender psicologicamente daquilo”
    • Abrir o código como open source e desistir é o pivot para IA definitivo. Os novos modelos vão aprender com o que você fez e algum dia farão melhor

  • Não é a primeira vez que vejo uma história de um produto sem encaixe ideal tentando achar uma direção de pivot e escolhendo IA como resposta, só para fracassar
    Já falei isso antes, mas vale repetir. Quando entendermos no que a IA é boa e no que ela é ruim, vamos começar a tratá-la como ferramenta, e não como objetivo, e aí a geração de ideias de produto vai se estabilizar

    • Nós já sabemos. A IA é boa em inventar coisas plausíveis, e fraca em produzir resultados que resistam a fatos ou verificação
    • O produto em si era bom. Já estive em uma startup que pagava com prazer por esse produto de gerar SDKs a partir de especificações OpenAPI e tirava muito valor disso
      Então, para mim, o problema aqui não era adequação produto-mercado
    • Isso quer dizer que a IA não consegue automatizar algo a ponto de salvar uma ideia ruim de produto? Tipo, fazer de forma mais eficiente algo que ninguém quer não é um negócio
    • O conceito de API precisa desaparecer, e as IAs deveriam simplesmente conversar entre si em linguagem natural

  • Não sei muito bem como interpretar isso. Por um lado, aplaudo a autorreflexão, o fato de encarar verdades desconfortáveis e o fato de terem criado um conjunto de ferramentas bem amplo
    Mas, por dentro, parece ser uma ferramenta que envolve outras ferramentas. A ferramenta de classificação de APIs aparentemente delega boa parte do trabalho pesado à OpenAI
    “Você é um classificador de nível mundial. Encaixe estas APIs em um destes grupos.”
    O restante dos arquivos parece ser código de ligação, com as fronteiras entre modelo·visão·controlador um pouco borradas. Também havia testes, e eu pensei que isso seria importante em wrappers de ferramentas, onde há muitas mudanças fora do seu controle externo, mas na prática era algo no nível do teste funcional contextLoads() que o IntelliJ fornece por padrão: basicamente verificar se as dependências existem e se a compilação não falha
    Há visão e isso até se alinha ao princípio de Pareto, mas, enquanto validavam a hipótese de que o mercado não tem interesse em manter suas próprias coisas, a sensação é que internamente eles também não conseguiram resolver o próprio problema de manutenção
    Se tivessem conseguido resolver primeiro esse motivo para si mesmos, talvez pudessem resolvê-lo para outras pessoas também; mas isso parece um dilema em que é preciso ter um produto realmente usado para sentir a dor e ter empatia com o usuário final

  • Um startup que falhou não é algo de que se envergonhar. A maioria de nós nem sequer tem coragem de tentar
    É difícil esperar grande interesse pelo código. O valor do código de uma empresa sem o negócio e sem as pessoas é bem negativo, a menos que exista alguma arma secreta técnica realmente especial
    Mesmo que haja uma parte tecnicamente impressionante, as pessoas provavelmente só vão querer entender como aquela parte funciona, e não usar o código em si

    • Sou fundador da Konfig. Concordo 100%. Eu não recomendaria a ninguém tentar decifrar e implantar a Konfig diretamente
      Dito isso, um cliente conseguiu fazer o self-host da nossa plataforma de documentação enquanto buscava uma forma de lidar com as consequências do encerramento da Konfig
    • Depois de passar por alguns startups cada vez menos fracassados, foi isso que aprendi com muito custo
      Se você não tem um plano de negócios para gerar receita rapidamente ou um investimento enorme, não deveria criar uma startup de tecnologia. Em geral, se você não tem nem uma noção mínima de para onde o negócio vai, também é difícil conseguir investimento, e pessoas técnicas normalmente não entendem o lado comercial o bastante
      A maioria das empresas não é startup, é só empresa mesmo. Empresa com receita e contas para pagar. Startup é uma empresa que vive de tempo e dinheiro emprestados, sem receita, e especialmente se esse dinheiro for seu, você precisa de um plano
      A maioria das empresas com investimento de venture capital fracassa. O trabalho do venture capital é fazer as empresas que vão falhar falharem rápido, e sustentar seu próprio negócio com a minoria que não falha e explode em sucesso. “Aceleração” ou “captação de investimento” não significa que você está no caminho do sucesso; significa que você subiu num palco em que precisa vencer as probabilidades e não tem muito tempo restante
      Se a empresa bem-sucedida já tem receita, ela não precisa de venture capital. Então é preciso perguntar por que está falando com eles. Se é difícil gerar receita, venture capital não vai consertar isso
      Muitos VCs são preguiçosos e só demonstram interesse depois que você já deu certo. Por isso surge uma dinâmica estranha em que empresas que receberam investimento no começo fracassam, e empresas que não receberam acabam tendo sucesso
      A empresa atual está há 4 anos operando totalmente em bootstrap. Sofremos para gerar receita, encaixamos trabalho no tempo disponível, e eu vivo principalmente de consultoria paralela. A empresa teve os três anos mais bem-sucedidos seguidos e está se aproximando do ponto em que poderei largar a consultoria e focar no negócio, mas foi uma jornada longa
      Quanto a open source, publico tudo o que não é código específico do negócio nem propriedade intelectual central. Um grande motivo também é que não quero recriar o mesmo trabalho braçal quando abrir a próxima empresa. Já vivi na pele como esse tipo de coisa atrasa
      Muita gente em startup é obcecada por propriedade intelectual, mas, na realidade, a maior parte do software não tem tanto valor assim. Ainda assim, leva tempo, dinheiro e energia para ser feito
      Por isso publico muitas ferramentas, frameworks e afins dos quais eu mesmo serei o principal usuário. Para continuar usando tudo isso no próximo projeto

  • O code dump em si pode ser interessante, mas aparentemente não há licença. Seria muito mais útil se viesse com uma licença open source adequada

    • Cerca de uma hora depois do comentário, foi adicionado um arquivo MIT LICENSE

  • O mercado de ferramentas para desenvolvedores é realmente difícil
    Quase toda decisão de arquitetura vira “que ferramenta open source podemos usar para resolver este problema?”
    Ninguém quer pagar, e tudo bem

    • Sim, mas a maioria dos desenvolvedores quase não percebe problemas fora daqueles que eles próprios vivem, e esses problemas geralmente são problemas de tooling para desenvolvedores
      Por isso tantas empresas acabam criando startups de developer tools, mesmo havendo necessidades enormes em outras áreas
      Se existisse uma forma de desenvolvedores experientes que querem começar algo encontrarem pessoas com problemas, expertise de domínio e vontade de empreender sem depender só de acaso e networking, acho que muito valor poderia ser destravado
    • Vender ferramentas para desenvolvedores é difícil. Você precisa competir com uma infinidade de ferramentas open source que continuam se adaptando e mudando, e boas ideias são rapidamente absorvidas e copiadas
      Por isso, a maioria das ferramentas comerciais tem vida útil limitada em termos de utilidade e costuma ficar na categoria de “bom ter”
      Além disso, muitos desenvolvedores são empregados e não têm orçamento pessoal para ferramentas. O mercado acaba se restringindo, na prática, a desenvolvedores freelancers ou a gestores que contratam desenvolvedores
      Gestores de equipes analisam esse tipo de gasto com cuidado e normalmente também não têm muito orçamento. Na maioria das empresas, simplesmente não existe orçamento individual de ferramentas para desenvolvedores
      Freelancers também costumam usar as ferramentas adotadas pela empresa que os paga, e na maioria das vezes são ferramentas gratuitas. Ferramentas pagas complicam ainda mais o uso de freelancers, porque é preciso lidar até com licença para contratados. Então há uma tendência de evitar esse tipo de ferramenta para manter tudo simples
    • Indo além, ferramentas para desenvolvedores são enganosamente difíceis. É fácil parecer que criar developer tools é a fórmula da vitória para uma empresa ou startup. Afinal, você também é desenvolvedor e provavelmente identificou um problema que já viveu na prática
      Você também sabe onde os desenvolvedores se reúnem e o que costuma funcionar bem, então parece que está tudo certo
      Mas, como foi dito, muitos desenvolvedores não querem pagar e procuram uma solução open source que faça o trabalho necessário, mesmo que seja um pouco menos conveniente. Além disso, do outro lado estão pessoas cuja profissão e vida giram em torno de criar software, então a resposta pode muito bem ser: “vou eu mesmo fazer isso”
    • Não é totalmente verdade. Eu só não quero desperdiçar tempo processando 50 cobranças de 10 dólares
      Será que não existe um negócio que consolide vários serviços numa única fatura? Ou ainda precisamos continuar usando AWS, Azure e GCloud?