Publico el código de mi startup que fracasó después de 3 años

 (dylanhuang.com)
3 puntos por GN⁺ 2024-12-18 | 1 comentarios | Compartir por WhatsApp
  • Konfig empezó como una startup de herramientas para desarrolladores que facilitaba la integración de API, pero cerró tres años después y publicó su codebase con el código del producto y materiales operativos
  • Su producto principal era un SDK Generator que creaba bibliotecas cliente a partir de especificaciones OpenAPI, y luego se amplió a documentación y un entorno interactivo de pruebas de API
  • Hubo cierta respuesta de algunos clientes startup, pero fue difícil convertirlo en un negocio de hipercrecimiento por la dificultad de cerrar contratos y los precios bajos
  • Después hicieron un pivot hacia un producto de IA vertical B2B SaaS, pero incluso tras múltiples entrevistas y procesos de ventas no encontraron una respuesta del mercado (traction) que diera confianza en un gran negocio
  • El repositorio público se publicó tal como estaba al momento del cierre, e incluye código del producto, experimentos del pivot, guiones de ventas, configuración de despliegue y el sitio web de marketing, sin limpieza ni correcciones

La herramienta para desarrolladores de API que construía Konfig

  • Konfig fue una startup de herramientas para desarrolladores de API iniciada a finales de 2022, enfocada en simplificar la forma en que los desarrolladores trabajan con API
  • Su objetivo era mejorar la generación de SDK, la documentación y las herramientas alrededor de las pruebas
  • Su producto principal era SDK Generator
    • Tomaba especificaciones OpenAPI como entrada y generaba bibliotecas cliente para varios lenguajes de programación
    • Después se amplió a herramientas de documentación de API y a un entorno interactivo de pruebas de API

Límites de crecimiento y pivot a IA

  • Hubo traction con algunos clientes startup, pero no logró convertirse en un negocio de hipercrecimiento
  • Era difícil cerrar contratos con clientes potenciales y, aun con un ROI demostrable, el nivel de precios era demasiado bajo
  • Tras el avance de la IA generativa, vieron una oportunidad para resolver problemas que antes eran difíciles de abordar e hicieron un pivot hacia un producto de IA vertical B2B SaaS
  • Evaluaron varias ideas mediante entrevistas con usuarios y ventas, pero no encontraron una traction suficiente como para dar confianza en una dirección que pudiera convertirse en un gran negocio

Un repositorio publicado tal como estaba al cerrar

  • El repositorio público es konfig-dev/konfig
  • El repositorio se publicó exactamente en el estado en que estaba cuando la empresa cerró
    • Sin limpieza
    • Sin pulido
    • Sin correcciones
    • El codebase muestra el estado real, sin filtrar, del código de una startup

Principales productos creados durante 3 años

Código operativo y experimentos publicados junto con el repositorio

Reflexión final del fundador

  • Dylan Huang dejó su trabajo en marzo de 2022 para dedicarse por completo a la startup, asumiendo el reto aun sabiendo que podía fracasar
  • Considera este fracaso como una experiencia que le enseñó más que el éxito
  • Como siguiente paso, planea explorar nuevas oportunidades, buscar un puesto adecuado en el mercado laboral y seguir aprendiendo y creciendo
  • También deja abierta la posibilidad de volver a construir algo por su cuenta algún día

Lecturas relacionadas

1 comentarios

 
GN⁺ 2024-12-18
Opiniones de Hacker News

  • Me pregunto cuántos excelentes productos de nicho habrían quedado para estas alturas si, en vez de apuntar a un “negocio enorme” de “crecimiento ultrarrápido”, hubieran apuntado a un negocio pequeño.

    • Es fácil decirlo, pero en la práctica es realmente difícil, porque hay que aguantar 3 a 5 años prácticamente sin sueldo y esperar resultados parecidos a los de un negocio con inversión.
      Para que una startup de 2 o 3 personas sobreviva en un país desarrollado, tiene que vender una enorme cantidad de licencias de 10 dólares al mes, y también hay que considerar el costo de oportunidad.
    • Si recibes inversión para cubrir los costos necesarios de cada mes, desde la perspectiva del inversionista tiene que existir posibilidad de crecimiento ultrarrápido para que cierren los números del portafolio.
      Si desde el principio apuntas a un negocio pequeño y sostenible y tienes éxito, puedes evitar la inversión; pero si hiciste un pivote hacia una dirección completamente nueva en la etapa media o tardía de la empresa, es muy probable que ya hayas quemado la mayor parte de las reservas.
    • Con ese resultado, tiene más sentido entrar a trabajar en una empresa grande y recibir una compensación similar sin riesgo.
    • A mí también me daba curiosidad esta parte. Soy uno de tres cofundadores de una empresa bootstrap que hace consultoría en una región de bajo costo de vida; durante varios años les hemos pagado a los fundadores 50 mil dólares al año, y nos ha ido bastante bien sin haber tenido una suerte especialmente extraordinaria ni un criterio de negocio increíble.
      Este año los ingresos fueron de 400 mil dólares, las ganancias de 150 mil dólares y el crecimiento de 40%; además, el panorama comercial mejoró muchísimo frente a inicios de año. Esperamos un crecimiento fuerte también el próximo año, y estamos lejos de la saturación del mercado, así que hay margen para crecer durante varios años más.
      Sumando el sueldo y un tercio de las ganancias, este año son 100 mil dólares; con un crecimiento de 40%, la empresa se duplica cada dos años. Si todo sale bien, solo con sueldo y ganancias la cosa se pone bastante buena, y además existe la posibilidad de una venta con la que los fundadores podrían ganar millones de dólares.
    • Aquí se siente el subtexto de “¿ves?, ¡te dije que era difícil!”.
      Intentar crear una empresa como Google e intentar crear una empresa como Basecamp son ambas opciones válidas; simplemente son tipos distintos de empresas.
      Más bien, es fácil subestimar el riesgo de crear un “negocio de bajo riesgo”, y todos los negocios son difíciles. Aplausos para Konfig.

  • Como cliente de Konfig, esto me da mucha pena. Tal vez fuimos su primer cliente, y creo que incluso se nos mencionaba en commits iniciales.
    Dylan y Anh-Tuan nos resolvieron de forma excelente varios problemas reales. Ofrecían en un solo lugar SDK generados y documentación/tutoriales alojados con buen aspecto, y permitían que los usuarios llamaran a nuestra API para experimentar de inmediato con datos reales.
    Antes de Konfig, escribíamos a mano SDK que envolvían nuestra API de forma bastante desordenada, y alojábamos la documentación en ReadMe, pero no funcionaba bien de manera interactiva por los requisitos de firma de solicitudes de nuestra API.
    Gracias a que Konfig lo publicó como open source, ahora alojamos la documentación nosotros mismos: https://docs.snaptrade.com/
    Respeto muchísimo a este equipo, y ojalá hubieran encontrado alguna forma de seguir.
    Si estás operando un producto como Konfig, que a los clientes les encanta pero cuyos ingresos no crecen tanto como necesitas, vale la pena considerar subir más los precios. Nosotros habríamos pagado 2 o 3 veces lo que Konfig nos cobraba, y habríamos pagado más a medida que crecíamos, pero ellos nunca lo pidieron ni crearon cobros basados en uso, como una tarifa mensual por SDK o por demo.

    • Conocí Konfig a través de tu producto. La documentación era tan buena que no pude evitar investigar qué usaban detrás, y de verdad es mejor que Swagger o Redoc.
    • Me pregunto si no probaron usar directamente https://github.com/OpenAPITools/openapi-generator.
    • Si quieres una alternativa ligera para documentación de API, recomiendo Scalar. Es simple y fácil de usar, pero mucho mejor que la documentación de Swagger.

  • La cultura startup de EE. UU. es realmente extraña. No todo tiene que escalar a toda velocidad, y no todo tiene que ser enorme
    Los negocios deberían enfocarse más en la sostenibilidad, no en pivotear tres veces durante 2 o 3 años y luego cerrar

    • Por un lado es cierto, pero por otro, esa concentración obsesiva en “escalado gigantesco o fracaso” probablemente fue lo que empujó al ecosistema startup estadounidense hasta donde está hoy, y la razón por la que está tan por delante del resto del mundo
      Si a muchos fundadores de startups europeas les dices: “en 5 años te estancas con 15 a 20 empleados, tienes un flujo de caja estable y te pagas entre 200.000 y 250.000 dólares al año”, lo considerarían un gran éxito. En EE. UU., sobre todo si levantaste capital de riesgo, eso podría verse como un fracaso
      Una vez escuché a un VC de Silicon Valley decir abiertamente: “si consideras un éxito vender la empresa por 50 millones de dólares, tienes la mentalidad equivocada y no quiero trabajar contigo”
      Si te conformas con pequeños éxitos y crecimiento estable sin asumir grandes desafíos y grandes riesgos, nunca obtendrás grandes recompensas. Para una persona puede ser más saludable, pero para la economía en su conjunto puede ser malo
    • Creo que los pequeños negocios rentables, es decir, empresas que quizá parecen aburridas, con equipos pequeños y objetivos de largo plazo, no suelen llegar a la portada de HN porque no se fijan metas irrealmente grandes
      Es interesante que esta cultura adopte una mentalidad tipo “muévete rápido y rompe cosas”, pero parece aplicarse sobre todo a la industria tecnológica. También está eso de llamar “emprendedor serial” a un empresario que fracasó varias veces; es difícil ver como éxito vender una empresa insostenible
      Da risa imaginar cómo se sentiría si alguien que fracasó en varios deportes se llamara a sí mismo “atleta serial”
    • El problema es que, en el momento en que recibes capital de riesgo, te empujan hacia el escalado gigantesco
      Si no recibes capital de riesgo, salvo que puedas autofinanciarte con algo como consultoría, el camino hasta volverte autosustentable es mucho más difícil y largo. El modelo aquí es 37 Signals, pero ellos son una excepción enorme porque son la empresa que creó Rails
      Y aun si llegas a ese punto, un competidor con capital de riesgo puede entrar con mejores contactos y financiamiento, y aplastarte
    • Estoy en Europa y trabajo en una empresa que atraviesa exactamente las mismas dificultades
      Los ciclos de venta B2B a grandes empresas son absurdamente largos, y los precios a los que puedes venderle a pymes no alcanzan
      Aunque aportemos valor y ahorremos tiempo a los clientes, explicar ese valor siempre es difícil
      El pasto siempre parece más verde del otro lado, pero si al hacer un negocio B2B tienes que repetir las mismas penurias durante años para mantener las luces encendidas, tener conversaciones parecidas cada mes con clientes distintos y explicar 10 veces al año, de la misma manera, por qué tienes valor, entiendo que la gente no quiera quedar atrapada ahí. El burnout también puede llegar rápido
      Por eso también entiendo el deseo de encontrar una idea de negocio con un valor claro, donde la gente grite “toma mi dinero”
    • Hay varios factores por los que las empresas occidentales prefieren la expansión vertical en vez de la horizontal
      El primero es el retorno de inversión. Si atraes dinero de otros, esas personas obviamente esperan ganancias, y un inversionista inteligente diversifica su portafolio, así que sabe que muchas inversiones fracasarán. Por eso presionan a todas las inversiones para que crezcan lo más posible, para compensar las pérdidas, y hacen que unas pocas empresas de desempeño extraordinario cubran los fracasos
      Este crecimiento vertical no se ve solo en startups, sino también en grandes empresas. Creo que ahí influyen mucho el formalismo, el exceso de regulación y la burocracia. Si tienes que pasar por incontables trámites como permisos, configuración de cuentas fiscales y de nómina, y todavía más trámites si quieres salir a bolsa, ampliar el alcance de actividades de una empresa ya establecida puede ser mucho más barato y menos riesgoso que separar y crear una nueva empresa

  • Parece que éramos competidores. Soy el fundador de ReadMe.com, y nosotros ofrecemos documentación de API, SDK y demás
    No sé exactamente por qué nosotros tuvimos éxito, pero yo también pasé por muchísimos falsos comienzos y fui iterando poco a poco la idea central hasta llegar a un punto en que la gente se emocionaba de manera visible
    Como sabía que este mercado era difícil, dediqué mucho tiempo y esfuerzo a cosas que no eran de ingeniería, y Hacker News siempre fue favorable con nosotros, especialmente cuando nos mostrábamos con más honestidad
    Voy a intentar contactarlo en privado porque me gustaría escuchar más
    En general, felicidades por todo el esfuerzo invertido. Empezar una empresa y creer en uno mismo es algo increíblemente difícil, y puedes sentir orgullo por ello

    • Quizá la razón por la que ReadMe tuvo más éxito que Konfig fue que empezó 8 años antes. Konfig era una buena idea y la ejecutaron bien, pero puede que simplemente no haya sido el momento adecuado
    • Ya que estamos, diré que el efecto de transición CSS de la pantalla de login de ReadMe sigue siendo uno de los elementos de branding más fuertes que recuerdo. Quien lo haya ideado hizo algo realmente excelente

  • Creo que veremos mucho este resultado en el futuro cercano. A medida que se desinfle la burbuja de la IA, se repetirán cosas parecidas

    • Creo que habría respetado más ese esfuerzo si lo hubieran escrito así
      “Intentamos aplicar IA generativa a un producto SaaS B2B vertical, pensando que podía resolver problemas que antes no se podían resolver. Creamos y propusimos varias ideas, pero la respuesta de los usuarios no fue lo bastante positiva como para darnos la certeza de que esa era la dirección correcta para construir un gran negocio.”
      Tal como está el texto original, la primera impresión que da es: “la persona que escribió esto está tan metida en una cultura de moda temporal y estrecha que me genera rechazo instintivo, y ni siquiera justo después de fracasar por completo logra salir psicológicamente de ahí”
    • Abrir el código como open source y rendirse es el pivote de IA definitivo. Porque los nuevos modelos aprenderán de lo que hiciste y algún día lo harán mejor

  • No es la primera historia de un producto que no encajaba del todo, buscó una dirección para pivotear, tomó la IA como respuesta y fracasó
    Ya lo dije antes, pero vale la pena repetirlo. Cuando entendamos en qué es buena y en qué no es buena la IA, empezaremos a tratarla como una herramienta, no como un objetivo, y la generación de ideas de producto también se estabilizará

    • Ya lo sabemos. La IA es buena para inventar contenido que suena plausible, y es débil para producir resultados que resistan hechos o verificación
    • El producto en sí estaba bien. Estuve en una startup que pagaba con gusto por ese producto que genera SDK a partir de especificaciones OpenAPI y obtenía mucho valor de él
      Así que creo que aquí el problema no era el encaje producto-mercado
    • ¿Quieres decir que la IA no puede salvar una mala idea de producto automatizando algo? Como que hacer de forma más eficiente algo que nadie quiere no es un negocio
    • El concepto de API debería desaparecer, y simplemente deberíamos hacer que las IA conversen entre sí en lenguaje natural

  • No estoy muy seguro de cómo interpretar esto. Por un lado, aplaudo la introspección, el haber enfrentado verdades incómodas y el haber creado un conjunto de herramientas bastante amplio
    Pero si miras por dentro, son herramientas que envuelven herramientas. La herramienta de clasificación de API parece delegar buena parte del trabajo pesado a OpenAI
    “Eres un clasificador de nivel mundial. Encaja estas API en uno de estos grupos.”
    El resto de los archivos son código de cableado y límites algo borrosos entre modelo, vista y controlador. También vi tests, y pensé que serían importantes al envolver herramientas donde habrá muchos cambios fuera de tu control, pero en la práctica parecían limitarse a comprobar que hay dependencias y que la compilación no falla, como el test funcional contextLoads() que IntelliJ da por defecto
    Hay visión y está alineado con el principio de Pareto, pero da la sensación de que, mientras validaban la hipótesis de que el mercado no está interesado en mantener lo suyo, internamente tampoco lograron resolver su propio problema de mantenimiento
    Si hubieran podido resolver primero esa razón para sí mismos, podrían habérsela resuelto también a otros, pero eso parece un dilema: para sentir el dolor y empatizar con el usuario final, necesitas tener un producto que se use de verdad

  • Una startup fallida no es algo de lo que avergonzarse. La mayoría de nosotros ni siquiera tiene el valor de intentarlo
    Es difícil esperar mucho interés por el código. El valor del código de una empresa sin el negocio ni las personas, si no hay un arma secreta técnica especial, es bastante negativo
    Incluso si hubiera una parte técnicamente impresionante, lo más probable es que la gente solo quiera entender cómo funciona esa parte, no usar el código en sí

    • Soy el fundador de Konfig. Coincido al 100%. No le recomendaría a nadie intentar descifrar y desplegar Konfig directamente
      Dicho eso, un cliente sí logró desplegar por su cuenta nuestra plataforma de documentación mientras buscaba cómo manejar las consecuencias del cierre de Konfig
    • Algo que aprendí a la mala después de intentar varias startups cada vez menos fallidas es esto
      Si no tienes un plan de negocio para generar ingresos rápido o una enorme cantidad de inversión, no deberías crear una startup tecnológica. Normalmente, si no tienes al menos una intuición mínima de hacia dónde irá el negocio, también es difícil levantar inversión, y los técnicos por lo general no entienden lo suficiente el lado del negocio
      La mayoría de las empresas no son startups, son simplemente empresas. Tienen ingresos y pagan facturas. Una startup es una empresa que vive con tiempo y dinero prestados, sin ingresos, y necesita un plan, sobre todo si ese dinero es tuyo
      La mayoría de las empresas financiadas con capital de riesgo fracasan. El trabajo del capital de riesgo es hacer que las empresas que van a fracasar fracasen rápido, y sostienen su propio negocio con unas pocas que no fracasan y tienen un éxito explosivo. “Aceleración” o “levantamiento de inversión” no significa que estés en el camino del éxito; significa que te subiste a una posición donde tienes que ganarle a las probabilidades y no te queda mucho tiempo
      Si tienes una empresa exitosa con ingresos, no necesitas capital de riesgo. Entonces deberías preguntarte por qué estás hablando con ellos. Si te cuesta generar ingresos, el capital de riesgo no va a arreglar eso
      Muchos fondos de capital de riesgo son flojos y solo se interesan cuando ya tuviste éxito. Eso crea una dinámica extraña en la que las empresas que reciben inversión al inicio fracasan y las que no logran recibirla tienen éxito
      Mi empresa actual lleva 4 años operando completamente bootstrappeada. Sufrimos con los ingresos, metemos trabajo en el tiempo disponible y yo vivo principalmente de consultoría paralela. La empresa ha tenido su año más exitoso durante 3 años seguidos, y ya estamos cerca de que pueda dejar la consultoría y enfocarme en el negocio, pero ha sido un camino largo
      Sobre el open source, publico lo que no sea código específico del negocio ni propiedad intelectual central. Una gran razón es que no quiero volver a construir las mismas tareas tediosas cuando empiece la próxima empresa. Ya viví cómo esas cosas te frenan
      En startups hay mucha gente obsesionada con la propiedad intelectual, pero en la práctica la mayor parte del software no vale tanto. Aun así, crearlo consume tiempo, dinero y energía
      Por eso publico muchas herramientas, frameworks y cosas que yo seré el principal usuario. Para seguir usándolas en el próximo proyecto

  • El volcado de código en sí puede ser interesante, pero parece que no tiene licencia. Sería mucho más útil si le pusieran una licencia open source adecuada

    • Aproximadamente una hora después del comentario se agregó un archivo MIT LICENSE

  • El mercado de herramientas para desarrolladores es realmente difícil
    Casi toda decisión de arquitectura se vuelve “¿qué herramienta open source puedo usar para resolver este problema?”
    Nadie quiere pagar, y eso está bien

    • Es cierto, pero la mayoría de los desarrolladores casi no percibe problemas fuera de los que ellos mismos sufren, y esos problemas normalmente son problemas de herramientas para desarrolladores
      Por eso terminan existiendo muchas empresas que crean startups de herramientas para desarrolladores, aunque hay una necesidad enorme en otras áreas
      Si hubiera alguna forma, además de la casualidad y el networking, de que desarrolladores experimentados que quieren empezar algo encontraran personas con problemas, experiencia de dominio y ganas de emprender, creo que se podría liberar mucho valor
    • Vender herramientas a desarrolladores es difícil. Tienes que competir con montones de herramientas open source que se adaptan y cambian todo el tiempo, y las buenas ideas se absorben y se copian rápido
      Por eso la mayoría de las herramientas comerciales tiene una vida útil limitada en términos de utilidad, y en general se queda en algo que está bueno tener
      Además, muchos desarrolladores son empleados y no tienen un presupuesto personal para herramientas. El mercado en realidad se reduce a desarrolladores freelance o a managers que emplean desarrolladores
      Los managers de equipo revisan con mucho cuidado este tipo de gastos y normalmente tampoco tienen mucho presupuesto. En la mayoría de las empresas no existe algo como un presupuesto individual de herramientas para desarrolladores
      Los freelancers también suelen usar las herramientas que usa la empresa que les paga, y esas son en su mayoría herramientas gratuitas. Las herramientas pagas obligan a preocuparse incluso por licencias para contratistas, lo que complica más trabajar con freelancers. Por eso tienden a evitarlas para mantener las cosas simples
    • Más aún, las herramientas para desarrolladores son engañosamente difíciles. Es fácil que crear herramientas para desarrolladores parezca una fórmula ganadora para una empresa o startup. Tú también eres desarrollador, y probablemente encontraste un problema que sufriste en el pasado
      También sabes dónde se reúnen los desarrolladores y qué cosas funcionan bien con ellos, así que todo parece estar bien
      Pero, como dijeron, muchos desarrolladores no quieren pagar y buscan una solución open source que haga lo necesario, aunque sea un poco menos cómoda. Además, como del otro lado hay personas cuyo trabajo y vida consisten en crear software, la respuesta también puede ser “bueno, lo hago yo mismo”
    • No es del todo cierto. Pero tampoco quiero perder tiempo procesando 50 facturas de 10 dólares
      ¿No existe un negocio que agrupe varios servicios en una sola factura? ¿O igual hay que usar AWS, Azure y GCloud?