Existe un formato de publicación de LinkedIn que seguramente has visto pasar. Sigue siempre el mismo guion. Un fundador anuncia que ha sido traicionado – por un desarrollador, un socio, un cliente comercial, a veces los tres a la vez. La historia se cuenta con líneas cortas, un ritmo fragmentado, puntos suspensivos dramáticos. Los detalles son lo suficientemente vagos para ser inverificables. La emoción está calibrada para provocar reacciones. Al final de la publicación, una llamada a la acción disfrazada de herida abierta: “Mis DM están abiertos.”
No es emprendimiento. Es marketing de quejas. Y merece ser nombrado por lo que es.
La anatomía del post-víctima
El formato es tan estandarizado que resulta parodiable. La historia comienza con una posición de confianza – “confiaba en él como a nadie”. Sigue la traición vagamente descrita – “copió exactamente lo que me había confiado”. Luego la resolución emocional – “me duele, pero no me detendré”. Y finalmente el giro comercial – una llamada de candidaturas para un CTO, una fase de pruebas anunciada, decenas de testers beta listos.
Lo que es hábil en este formato es su inmunidad estructural a la verificación. La historia es verdadera porque nos la dicen. El villano nunca es nombrado – lo que protege al autor legalmente mientras se deja al descubierto el sospezo sobre cualquiera en el entorno del proyecto. La víctima no proporciona pruebas porque “no es el momento”. Y cualquiera que cuestione la versión oficial se convierte automáticamente en enemigo de la causa.
Un caso concreto que algunos reconocerán
Tomemos un ejemplo reciente, en un sector que conocemos bien — el de las soluciones de software para la restauración y la agregación de pedidos de entrega.
Un fundador lanza una plataforma destinada a centralizar los pedidos de Uber Eats, Deliveroo y otras plataformas para restaurantes. Varios meses después del anuncio del proyecto, primer post: un desarrollador freelance poco riguroso, poco avance, muchas excusas, fue necesario detenerlo. Lección de resiliencia. Comentarios de ánimo. Luego el silencio.
Algunos meses más, segunda publicación — ésta mucho más dramática. Otro desarrollador, de confianza esta vez. Conocido en la vida real. A quien se le había compartido todo: la visión, el producto, la estrategia. Y quien, según la narración, habría copiado todo. Detalle particularmente sabroso: el desarrollador tenía acceso al repositorio de GitHub del proyecto — pero el fundador no. El proyecto se presenta como estando “a dos meses de la fase de pruebas, con decenas de restauradores listos para probar la solución”. Conclusión de la publicación, memorable: “Solo es código. El problema que [el proyecto] resuelve, él, es real.” DM abiertos para un futuro CTO.
Dos publicaciones. Dos desarrolladores. Dos traiciones. Ningún cliente entregado. Ninguna funcionalidad demostrada en condiciones reales. Pero una audiencia que crece con cada episodio, y un proyecto que permanece bajo los focos sin tener que probar nada.
Es exactamente el mecanismo.
Lo que este formato produce, concretamente
Miles de “me gusta” de personas que solo conocen una versión. Cientos de comentarios de ánimo que amplifican la narrativa sin cuestionarla. Una audiencia nueva atraída por la emoción, no por el valor del producto. Y una legitimidad de fundador que sobrevive —a veces prospera— sin que un solo cliente real haya sido atendido.
Es un arbitraje calculado. La reclamación pública cuesta menos que la ejecución. Genera más visibilidad en una semana que un lanzamiento real en seis meses. Y posiciona a su autor como un superviviente valiente en lugar de alguien que no supo gestionar sus relaciones profesionales básicas – como firmar un contrato antes de compartir su propiedad intelectual, o mantener el acceso a su propio repositorio de código.
Aquí está la pregunta que nadie se plantea bajo estas publicaciones: si se hubiera firmado un contrato desde el primer día – si los accesos al depósito se hubieran protegido desde el principio – ¿dónde estaría la traición? La respuesta incómoda es que la mayoría de estas historias nunca habrían ocurrido con un mínimo de rigurosidad profesional. Pero admitir eso es admitir una falta. Y la falta no es una buena historia para LinkedIn.
La otra versión
En la casi totalidad de estos conflictos públicos, existe otra versión. Una versión en la que el “desarrollador ladrón” era en realidad un profesional que había construido algo que el fundador no era capaz de construir solo, y que se encontró con demandas que salían del marco de una relación profesional normal: exigir código sin contrapartida legal, por ejemplo, o solicitar datos pertenecientes a un tercero. Una versión en la que el “código copiado” existía bien antes de que el fundador descubriera el sector. Una versión en la que la ruptura fue iniciada no por una traición, sino por un rechazo a firmar condiciones inaceptables, y donde depositar su código en el INPI –acto perfectamente legítimo de todo desarrollador responsable– repentinamente fue calificado como traición.
Esta versión existe. Nunca ha sido publicada en LinkedIn. Porque la persona que la viviría no tendría interés en responder públicamente a alguien que no la ha nombrado – y porque cualquier respuesta sería interpretada como una confirmación de culpabilidad. Es uno de los mecanismos más pervers de este formato: la víctima habla, el profesional imputado se mantiene en silencio, el silencio se convierte en confesión.
La infantilización del storytelling
Lo que realmente está en juego en estas publicaciones, no es el dolor de un fundador. Es una estrategia de posicionamiento personal. Y es de sobre todo eficaz porque se apoya en recursos emocionales reales – la traición, la soledad emprendedora, la resiliencia – para construir una audiencia en torno a una narrativa cuyo autor controla todos los parámetros.
El problema no es que un fundador comparta sus dificultades. Las verdaderas dificultades merecen ser compartidas. El problema es cuando la dificultad es fabricada, amplificada o dirigida para servir un objetivo comercial disfrazado de autenticidad. Cuando el momento de la publicación es perfecto – a dos meses de una fase de pruebas anunciada, justo antes de un reclutamiento, justo a tiempo para cuando el proyecto necesita visibilidad para existir. Cuando la narración se repite sobre el mismo proyecto con personajes diferentes, cada episodio añadiendo una capa dramática adicional. Cuando las súplicas se convierten en canales sistemáticos hacia los DM, las listas de espera, las candidaturas de CTO.
Es una tontería vestida de relato de fundador. Y LinkedIn se ha convertido en el escenario ideal, porque la red no tiene cultura de verificación ni memoria larga.
¿Por qué funciona y por qué perjudica?
Funciona porque estamos cableados para la simpatía. Una persona que sufre desencadena una respuesta emocional antes de cualquier análisis racional. Los algoritmos de LinkedIn amplifican los contenidos de alta reacción emocional. Y la comunidad emprendedora ha desarrollado una cultura de apoyo incondicional a los fundadores – legítima en muchos casos, explotable en otros.
Anochece porque los verdaderos profesionales – desarrolladores experimentados, CTO, socios técnicos – ven su reputación expuesta sin derecho a réplica efectivo. Porque los verdaderos casos de traición empresarial se ahogan en un flujo de dramas instrumentalizados. Porque los testers beta, los inversores, los socios toman decisiones basándose en una sola versión no verificada. Y porque decenas de restaurantes – que quizás habían manifestado un interés real en una solución de entrega – se encuentran esperando un producto del cual nadie puede garantizar que jamás verá la luz.
Lo que dice de un proyecto
Un fundador serio no construye su audiencia sobre sus heridas. La construye sobre resultados. Sobre clientes que testifican con su verdadero nombre y su verdadero restaurante. Sobre un producto que funciona en condiciones reales. Sobre métricas verificables. Sobre contenido que aporta valor real a quienes lo leen.
La victimización pública es inversamente proporcional a la solidez del proyecto. No porque los fundadores serios no tengan dificultades – las tienen, a menudo más que los demás – sino porque tienen suficiente con sus verdaderos problemas para no invertir tiempo en la puesta en escena de sus dramas.
Cuando un proyecto no muestra nada después de varios meses de existencia pública, sin demostración funcional, sin cliente en producción, sin funcionalidad verificable — pero con dos historias de traición bien documentadas y una cuenta de LinkedIn activa — es una información. Puede ser la información más útil que jamás ha entregado.
La buena pregunta
La próxima vez que leas uno de estos posts, pregúntate una sola pregunta: si esta historia es verdadera, ¿qué dice sobre la rigurosidad con la que este fundador gestiona su empresa? Si los contratos no están firmados, si la propiedad intelectual no está protegida, si el acceso al depósito de código no pertenece al fundador mismo — no se trata de mala suerte. Se trata de gestión.
Si esta historia se instrumentaliza — en su totalidad o en parte — para generar simpatía y audiencia a falta de generar clientes, ¿qué dice esto de lo que podemos esperar del producto en términos de seriedad y transparencia?
Ambas hipótesis son incómodas. Sin embargo, merecen ser planteadas, en silencio, antes de hacer clic en « Apoyar ».
Le soleil se couchait, peignant le ciel de couleurs flamboyantes. Les oiseaux chantaient leur dernière chanson de la journée, et une brise légère caressait la peau. C’était un moment de paix et de sérénité, un instant précieux à savourer.
En Fooderise, la única historia de marketing que importa es la tuya. Más de 500 restaurantes activos, plataforma disponible al 99,9%, tarifa pública, prueba sin tarjeta de crédito. Sin drama de LinkedIn. Solo una herramienta que funciona.
Rejoignez la communauté Fooderise
Recevez plus de conseils comme celui-ci directement sur WhatsApp. Gratuit, sans spam.
Rejoindre la chaîneUne correction ou une suggestion ?
Vous êtes éditeur, restaurateur ou expert du secteur et vous repérez une information à corriger ou à compléter ? Aidez-nous à tenir cet article à jour.
Proposer une amélioration