Esta guía explica cómo montar ese hábito en menos de tres horas semanales, qué publicar para que atraiga clientes reales en España y dónde están los límites cuando trabajas con NDAs.
¿Cuántos clientes te han llegado por algo que publicaste hace meses, mientras tu última propuesta la ganó otro freelance con la mitad de tu experiencia? Es la paradoja del dev que trabaja bien y comunica poco: tu código no aparece en Google, tu nombre sí puede. Build in public, construir en abierto, es la práctica de documentar públicamente lo que haces mientras lo haces: decisiones técnicas, errores, métricas de tus proyectos.
¿Qué es build in public y por qué funciona para developers?
Resumen clave: ¿Qué es build in public y por qué funciona para developers? LinkedIn: el escaparate comercial Para clientes B2B españoles, LinkedIn sigue siendo el punto de entrada. ¿Es compatible build in public con un NDA?
Build in public es la práctica de compartir de forma regular y documentada el proceso de tu trabajo técnico, decisiones, herramientas, fallos y resultados medibles, en canales abiertos como un blog, LinkedIn o un README de GitHub. No es enseñar el código del cliente: es contar cómo piensas un problema técnico y cómo lo resuelves.
Funciona por tres mecanismos que se refuerzan. Primero, prueba de competencia: un post técnico con detalle verificable demuestra más nivel que cualquier línea de «passionate about technology» en un CV. Segundo, recencia: el cliente que te busca hoy encuentra lo que publicaste esta semana, no un portfolio actualizado una vez al año. Tercero, admisibilidad: quien lee tus tres últimos posts llega a la reunión de venta medio convencido, el contenido hace de propuesta previa. El efecto compuesto es el que importa: publicar cada semana durante seis meses genera un archivo consultable que responde por ti cuando no estás en la sala.
Qué publicar: el criterio de la demanda visible
El error clásico es publicar lo que apetece escribir; el criterio correcto es publicar donde la demanda ya es visible. Según los datos de SeniorStack, de las 103 ofertas activas de Frontend en remoto en España (Q3 2026), React aparece en el 59,2 % y TypeScript en el 51,5 %; de las 231 ofertas activas de Cloud & DevOps, Kubernetes aparece en el 35,9 %, CI/CD en el 32,0 % y Terraform en el 29,9 %. Además, el 100 % de las ofertas de frontend en remoto publican descripción detallada del puesto, con las tecnologías nombradas una por una. Esa es la lista de la compra de un editor: cada tecnología que aparece en un tercio de las ofertas es un tema sobre el que decenas de empresas españolas tienen un problema real este trimestre. Un post «cómo reduje el tiempo de despliegue de 40 minutos a 6 en una plataforma Kubernetes» ataca exactamente esa demanda medible. Por el contrario, escribir sobre tu librería favorita de nicho sin oferta asociada puede dar satisfacción personal, pero construye poco pipeline. La regla práctica de SeniorStack: una tecnología con presencia >20 % en tu especialidad justifica contenido recurrente; por debajo del 10 %, un post puntual basta.
El test de las tres preguntas antes de publicar
Antes de darle a publicar, pasa el borrador por tres filtros rápidos. Uno: ¿contiene al menos una cifra? Un tiempo, un coste, un porcentaje, la cifra es lo que convierte una opinión en evidencia y lo que los lectores citan al compartir. Dos: ¿podría reproducirlo un lector con su caso? Si tu proceso solo funciona en tu contexto exacto, generaliza el método o publícalo como caso, pero no lo vendas como guía. Tres: ¿sobreviviría a que lo leyera el tech lead más exigente que conoces? Publicar en abierto somete cada pieza a revisión pública permanente, y eso es una ventaja: cada corrección que recibes en los comentarios es feedback gratuito de gente que sabe. Las piezas que fallan el tercer filtro son las que más enseñan al autor, y, bien respondidas en los comentarios, las que más reputación construyen.
Los cuatro formatos que más convierten
- Post-mortem técnico: «qué rompí en producción y cómo lo arreglé», el formato con mejor relación esfuerzo/credibilidad, porque nadie finge un post-mortem.
- Antes/después con métricas: LCP de 4,1 s a 1,8 s; coste de infra de 890 € a 310 €/mes. Una cifra de mejora vale más que diez adjetivos.
- Decisión de arquitectura comentada: por qué descartaste la opción obvia; muestra criterio, que es lo que los clientes senior compran.
- Proyecto personal con changelog público: la forma más honesta de build in public cuando el trabajo de clientes está bajo NDA.
Dónde publicar: el mapa de canales para el mercado español
No necesitas estar en todos los canales; necesitas un canal principal y dos secundarios con reglas distintas. El canal principal es donde resides el archivo (blog propio o publicaciones de LinkedIn); los secundarios llevan el tráfico.
LinkedIn: el escaparate comercial
Para clientes B2B españoles, LinkedIn sigue siendo el punto de entrada. La táctica que funciona: una publicación semanal de 150-300 palabras con una sola idea técnica y una métrica, más comentarios útiles en conversaciones de tu especialidad. La optimización del perfil es la mitad del trabajo, la guía de LinkedIn para developers de SeniorStack cubre palabra clave por palabra clave cómo aparecer en búsquedas de clientes.
GitHub: la prueba material
Un README de perfil con tus tres piezas de contenido mejores, y repositorios de proyectos personales con documentación cuidada. Para muchos tech leads que contratan, el GitHub es la entrevista previa: un repo con buen README demuestra comunicación técnica sin que nadie te la pregunte. Si quieres ir más allá, el open source como estrategia de marca personal es la versión avanzada de este canal.
Blog propio: el activo que acumula
Las redes caducan en 48 horas; tu blog compone el archivo indexable. Un post mensual de 1.500+ palabras sobre un problema de tu especialidad, con estructura clara, es lo que Google, y cada vez más los asistentes de IA que los clientes usan para buscar perfiles, pueden citar. La estrategia completa de contenido técnico que trae clientes merece lectura aparte.
Comunidades: donde se prueba la reputación
Slacks y Discords de comunidades tech españolas, hilos de Reddit especializados o eventos locales: el contenido allí no se publica, se participa. Responder bien una duda compleja delante de trescientos devs genera más confianza que diez posts autopromocionados.
El sistema: publicar en abierto sin quemarte ni quemar el NDA
El hábito sobrevive solo si el coste semanal es bajo: tres horas bien repartidas dan para un mes entero de presencia. La receta mínima: lunes, 30 minutos para anotar una decisión o hallazgo de la semana anterior en un fichero de borradores; miércoles, 60 minutos para convertir el mejor borrador en post de LinkedIn y, cada tres o cuatro semanas, en post de blog; viernes, 20 minutos para responder dos o tres conversaciones ajenas en comunidades. Con ese ritmo, en un trimestre tienes doce piezas publicadas y en seis meses el archivo empieza a funcionar solo, los clientes encuentran tres o cuatro entradas tuyas antes de escribirte.
El límite legal: qué no se publica jamás
Lo que el NDA cubre no se publica ni anonimizado a medias: nombres de clientes, capturas de entornos, datos de negocio, arquitecturas reconocibles. Lo que sí es tuyo: las decisiones técnicas genéricas, las técnicas de diagnóstico, las métricas de tus proyectos personales y las lecciones aprendidas desprovistas de contexto identificable. Cuando dudes, aplica la regla de oro: ¿podría el cliente reconocer su proyecto en esta historia? Si la respuesta es sí o quizá, no sale.
Las herramientas mínimas del sistema
El sistema no necesita stack: un fichero de borradores (Notion, Obsidian o un simple Markdown en tu repo), el programador de publicaciones de LinkedIn y un documento de métricas mensuales con dos filas, piezas publicadas y mensajes entrantes. Quien empieza montando un sistema editorial con cinco herramientas ya está procrastinando con estética de productividad. La única pieza opcional que sí devuelve la inversión es una plantilla de post-mortem: título del incidente, síntomas, diagnóstico, fix y prevención, veinte minutos por entrada y un formato repetible que además mejora la propia calidad de tus diagnósticos.
Qué esperar razonablemente en los primeros seis meses
Las expectativas desajustadas matan más hábitos de publicación que la falta de tiempo. La línea de tiempo honesta por trimestres: el primer trimestre produce casi nada medible, cero o un mensaje entrante, pocas visitas, y sirve para afianzar el ritmo y encontrar tu voz; abandonar aquí es el error estándar. El segundo trimestre empieza a devolver señales: alguna pieza indexa y recibe búsqueda orgánica, los primeros desconocidos comentan con preguntas técnicas y, si publicas en LinkedIn con constancia, las impresiones se estabilizan en un nivel donde los clientes potenciales ya te han visto varias veces. A partir del tercer trimestre, el archivo trabaja: los mensajes entrantes se vuelven periódicos y, lo más valioso, llegan pre-vendidos, citando tu post, con la pregunta técnica ya medio formulada. El consejo práctico: comprométete públicamente con un ritmo (una pieza semanal) antes que con un resultado, porque el ritmo es lo único que controlas los primeros meses.
De lectores a clientes: cómo convierte el contenido en abierto
El contenido no cierra ventas; abre conversaciones calificadas. El embudo típico: un post con métrica concreta → visita al perfil o blog → lectura de dos o tres piezas más → mensaje directo con una pregunta técnica → conversación comercial. Tu única tarea sistemática es facilitar el penúltimo paso: enlace al portfolio en la firma del post, caso de éxito accesible desde el perfil, y una propuesta clara de cómo trabajar contigo. Sobre esa base actúan la prueba social y el networking estructurado, que multiplican el efecto del archivo. Mide solo dos cosas al principio: mensajes entrantes de desconocidos al mes y de qué pieza llegaron, con eso basta para iterar.
Riesgos reales y cómo gestionarlos
Los tres riesgos con teeth: el NDA (gestionado arriba con la regla de reconocimiento), la sensación de exposición, publicar errores propios duele las primeras tres veces y después deja de doler, como el gym, y el timing, el miedo a «regalar conocimiento». Sobre este último, la experiencia repetida del mercado freelance es contundente: el cliente que puede implementarlo con tu post no tenía presupuesto para ti; el que sí tiene presupuesto quería exactamente esa evidencia de criterio. Regalar el cómo generalista nunca ha canibalizado el hacer concreto para un cliente concreto.
Preguntas frecuentes
¿Qué es build in public para un developer?
Es la práctica de documentar públicamente el proceso de trabajo técnico, decisiones, herramientas, errores y resultados medibles, en canales abiertos como LinkedIn, GitHub o un blog propio, sin revelar jamás información cubierta por NDA.
¿Cuánto tiempo hace falta dedicar a build in public?
Con tres horas semanales basta: 30 minutos de captura de notas, 60 de redacción y 20 de participación en comunidades, repartidos en días distintos. Ese ritmo produce una publicación semanal y un post de blog al mes, suficiente para construir un archivo consultable en seis meses.
¿Sobre qué tecnologías conviene publicar?
Sobre las que concentran demanda medible en tu especialidad. Según los datos de SeniorStack, React aparece en el 59,2 % de las 103 ofertas activas de Frontend en remoto en España, y Kubernetes en el 35,9 % de las 231 ofertas de Cloud & DevOps: una tecnología con más del 20 % de presencia justifica contenido recurrente.
¿Es compatible build in public con un NDA?
Sí, publicando solo lo que es tuyo: decisiones técnicas genéricas, técnicas de diagnóstico y métricas de proyectos personales. Nunca nombres de clientes, capturas de entornos ni arquitecturas reconocibles. La prueba: si el cliente podría reconocer su proyecto, no se publica.
¿Build in public sirve para conseguir clientes o solo reputación?
Sirve para abrir conversaciones calificadas: el embudo habitual va del post con métrica concreta a la lectura de más piezas y de ahí al mensaje directo con una pregunta técnica. El contenido no cierra ventas por sí solo, pero llega a la reunión de venta con el cliente medio convencido.
¿Qué diferencia hay entre build in public, portfolio y open source?
El portfolio demuestra resultados terminados; el open source demuestra código revisable; build in public demuestra el proceso, cómo piensas y resuelves mientras trabajas. Los tres se complementan: un portfolio estático se actualiza una vez al año, mientras que la publicación en abierto añade evidencia fresca cada semana, y un repositorio con changelog conecta ambas cosas.
¿Te está sirviendo SeniorStack? Añádenos a tus fuentes preferidas en Google y nos verás destacados en tus resultados y respuestas de IA.