Antes de un Demo Day o de una publicación en Launch YC, una startup necesita dos canales de entrada, y el correo de un fundador no puede ser ninguno de los dos: una página de empleo pública con un proceso de selección de verdad detrás, y un programa de divulgación de vulnerabilidades (VDP) como puerta de entrada, con su `security.txt`, una política acotada y un plazo de acuse de recibo. El 13 de agosto de 2026 sondeamos las 80 empresas que más recientemente habían publicado en Launch YC. Veinte tenían lo primero. Nueve, lo segundo.

Esa brecha no es negligencia. Es lo que pasa cuando dos tareas caen en la tierra de nadie entre las funciones de tres cofundadores y la fecha de lanzamiento llega igualmente.

## El Demo Day es un evento de tráfico y solo te has preparado para los inversores

Toda aceleradora fabrica un momento público con fecha. Lo has planteado como un evento para inversores. También es un evento para candidatos y para los bots que escanean, y esos dos flujos llegan a la misma dirección.

Así queda el calendario de los programas a los que los fundadores se apuntan de verdad, según lo publicado el 13 de agosto de 2026:

| Programa | El momento público programado |
|---|---|
| **Y Combinator** | Cuatro promociones al año. Demo Days de 2026: 24 de marzo, 16 de junio, 10 de septiembre y 2 de diciembre. Más Launch YC, de forma continua. |
| **Techstars** | Cohortes de mentoría de tres meses; 16 programas activos en el directorio. |
| **Antler** | 26 sedes en todo el mundo, candidaturas abiertas todo el año y cohortes que arrancan con regularidad. |
| **Entrepreneur First** | FORM en Londres y después un LAUNCH de 12 semanas en San Francisco. Al Demo Day asisten más de 200 socios de fondos de capital riesgo. |
| **a16z Speedrun** | Dos cohortes al año, de 60 a 70 equipos, con una tasa de admisión por debajo del 0,4 %. Demo Day de SR007: 6 de octubre de 2026. |
| **500 Global** | Programa presencial de cuatro meses en Silicon Valley. El plazo de la promoción 36 cierra el 11 de octubre. |
| **Alchemist** | Seis meses, solo grandes empresas y B2B. Demo Day virtual por invitación, con un pase previo presencial en San Francisco un mes antes. |
| **Sequoia Arc** | Dos cohortes al año, de unas 10 empresas cada una, construidas alrededor de un Arc Intensive de cuatro días. La página actual no anuncia ningún Demo Day. |
| **HF0** | «La residencia para fundadores en serie». El sitio lista promociones que empiezan el 13 de septiembre y el 4 de enero, y Demo Days el 4 de diciembre y el 1 de diciembre, sin indicar el año. |

Distinto capital, distintas ciudades, mismo hecho operativo: en una fecha que ya conoces, desconocidos intentarán ponerse en contacto contigo, y la única dirección publicada será la tuya.

**Launch YC es la versión más nítida de todo esto**, porque es una superficie pública permanente y no una sola tarde. YC lo abrió al mundo el 29 de junio de 2022, cuando sacó de Bookface una función interna y la llevó a ycombinator.com. Los fundadores publican cualquier día y a cualquier hora; los visitantes ordenan por sector, promoción y fecha de lanzamiento, y votan las empresas para que suban en la clasificación. Cuando TechCrunch lo cubrió, Lindsay Amos, de YC, describió la audiencia como fundadores, desarrolladores, inversores y personas que buscan trabajo. El tráfico de quien busca empleo es un objetivo de diseño explícito de la página. A 13 de agosto de 2026 acumulaba **3189 lanzamientos en total**, con más de 160 solo de la promoción de verano de 2026 en el mes previo a su Demo Day del 10 de septiembre.

## Qué llega de verdad el día del lanzamiento, y a qué velocidad

Llegan dos cosas: una ráfaga corta y concentrada de atención humana, y un goteo constante de escaneo automatizado que empezó antes que los humanos.

La mitad humana es real, pero breve. Un análisis de 41 301 publicaciones de Show HN y unas 100 000 marcas de tiempo de comentarios entre junio de 2025 y junio de 2026 encontró una **semivida mediana de atención de 7,2 horas**: el **90 % de los comentarios que una publicación recibirá en toda su vida llega antes de la hora 26** y solo un **4,2 % después de las 48 horas**. El mismo análisis deja una referencia que baja los humos: la mediana de los lanzamientos fue de 2 puntos y 0 comentarios, y el 61,7 % no recibió ningún comentario.

Para los lanzamientos que sí cuajan, las cifras se disparan rápido. El lanzamiento de Robinhood en Hacker News en diciembre de 2013, publicado por un tercero y no por los fundadores, produjo **10 000 registros el primer día y más de 50 000 en la primera semana**, según la charla de Kat Mañalac en la YC Startup Library. PostHog, entonces un equipo de tres personas de la promoción YC W20, contó **«bastante más de 200 registros»** y más de 800 estrellas en GitHub en los cinco días siguientes a su propio lanzamiento en HN. Y los datos de Ashby sobre unos 13 millones de candidaturas muestran que **el volumen de la primera semana de candidaturas entrantes es entre 2,5 y 3 veces mayor que el de cualquier semana posterior**. El pico llega exactamente donde tu proceso todavía no existe.

De la mitad automatizada se habla menos. El equipo Satori de HUMAN Security ha documentado que los atacantes vigilan los registros de transparencia de certificados, como CertStream, que dejan constancia pública de cada nuevo certificado TLS emitido. Un certificado recién emitido es, en sí mismo, la señal de que hay algo nuevo que escanear. En el trabajo con honeypots de HUMAN, **los escáneres supusieron de media el 69,5 % del tráfico de bots**, superando el 90 % algunos días, con aproximadamente un tercio de los intentos dirigidos a ficheros `.env` y otro tercio a datos de repositorios Git.

Mientras tanto, Hacker News le dice a quien publica un Launch HN que facilite trastear con el producto: **«Elimina las barreras de registro, al menos el día del lanzamiento; recibirás más y mejores comentarios»**. Es un buen consejo de lanzamiento. También significa que se te pide ampliar tu superficie de ataque justo el día en que tu certificado aparece en los registros de transparencia.

## Sondeamos las puertas de entrada de 80 empresas de Launch YC

El 13 de agosto de 2026 tomamos las 80 empresas más recientes de Launch YC (ventana de lanzamiento del 31 de julio al 13 de agosto de 2026, 80 dominios únicos) y comprobamos dos cosas: si tenían una página de empleo en una URL evidente y si contaban con un contacto válido para divulgación de vulnerabilidades.

**Empleo: 20 de 80 (25 %) devolvieron HTTP 200 en `/careers` o `/jobs`.** Un segundo sondeo con user agent de navegador dio 19 de 80; la diferencia, una petición que agotó el tiempo de espera. Léelo con precisión: un 404 en `/careers` no demuestra que una empresa no tenga página de empleo. Varias de las otras 60 pueden publicar sus puestos en un portal de empleo externo o en una ruta que no acertamos a adivinar. El hallazgo es que **no hay página de empleo en la URL evidente**, que sigue siendo la URL que un candidato teclea.

**Divulgación: 9 de 80 (11 %)** servían un `security.txt` válido según la RFC 9116, es decir, HTTP 200 con una línea `Contact:` en `/.well-known/security.txt` o `/security.txt`. **71 de 80 no tenían ninguno.**

La cifra más interesante es la de los nueve, porque **6 de esos 9 llevan al correo de un fundador** en lugar de a una dirección dedicada. Solo tres publicaban un alias `security@` de verdad. El único fichero que la especificación dice que un investigador debe descargar apunta, en dos de cada tres casos, a la persona que además está levantando ronda esa misma semana.

Las publicaciones de lanzamiento confirman en qué consiste realmente ese canal de entrada. De los 80 textos de lanzamiento, **55 (69 %) publican al menos una dirección de correo**, repartidas más o menos a partes iguales entre fundadores con nombre y alias genéricos. **Uno o dos de los ochenta incluían alguna señal de contratación, y exactamente uno mencionaba seguridad o divulgación**, y ese era texto de producto, no un canal para comunicar fallos. La foto es exactamente esta: el día de más tráfico en la historia de la empresa, el fundador publica una dirección personal ante todo internet, sin ningún filtro detrás.

**Decawork ilustra la tesis mejor que cualquier cifra agregada.** Se lanzó el 12 de agosto de 2026 con 135 votos, vendiendo «el plano de control de agentes para equipos de TI»: identidad, credenciales acotadas y aprobación de TI para agentes de IA. La línea `Contact` de su `security.txt` es un alias de fundadores. Su ficha en el directorio de YC enlaza el lanzamiento y muestra una pestaña de Empleo que marca cero. Una empresa del ámbito de la seguridad, con el canal de entrada en el correo del fundador y sin ninguna página de empleo pública. No es negligencia. Es el estado normal de un equipo de cuatro personas a tres semanas del Demo Day.

Hay un dato que rebaja el dramatismo. En los 1000 lanzamientos más recientes (una ventana de 11 meses, porque el índice limita cuánto se puede recuperar), **la mediana fue de 19 votos**, la media de 59,7, el máximo de 3085 y el **23,6 % obtuvo menos de 10 votos**. Para la mayoría de empresas, Launch YC por sí solo es un evento de poca atención. Lo que no puedes saber de antemano es qué clase de lanzamiento te va a tocar, y el canal de entrada tiene que existir antes de averiguarlo.

## Flujo uno: 298 candidaturas, 15 entrevistas y 21 horas que no tienes

Lo que entra por el lado de contratación en una empresa diminuta es mayor de lo que los fundadores esperan y recae sobre menos personas que en ningún otro tamaño de empresa.

El informe de Ashby de 2026 sobre contratación en startups, elaborado a partir de más de 1200 startups con respaldo de capital riesgo, 32 000 contrataciones y 11 millones de candidaturas, sitúa las **candidaturas entrantes por contratación en 298 para startups de menos de 25 empleados**. Por cada contratación cerrada, **15 candidatos llegan a una entrevista**, de modo que en torno al 95 % de lo que entra se descarta en el cribado antes de que nadie hable con nadie. Una contratación técnica consume unas **21 horas de entrevistadores**, extraídas de las mismas cuatro agendas que sacan el producto adelante.

El tiempo es la parte que los fundadores subestiman. En startups de menos de 25 empleados, contratar lleva **42 días con un reclutador implicado y 62 sin él**, y solo el **38 % de los puestos en ese tamaño cuenta con un reclutador**. Un equipo de cuatro personas está estructuralmente en la columna de los 62 días. Las herramientas siguen la misma escalera: **el 43 % de las startups de menos de 25 empleados usa IA en algún punto del reclutamiento, y la cifra sube al 57 %, al 66 % y al 77 %** a medida que la plantilla crece hasta la franja de 100 a 300. La ayuda va a parar a las empresas que menos la necesitan.

PostHog publicó cómo se vive esto desde dentro. En un puesto de marketing registraron **300 candidatos en los dos primeros días**, un récord de 900 en un solo día y más de 9000 candidaturas en 12 meses, con una media de 460 por puesto. Su reclutador interno dedicaba **menos de un minuto a cada una**. De esos primeros 300, **12 llegaron a entrevista**: un 4 %. PostHog tenía entonces unos 42 empleados, no cuatro. Ahora imagina el mismo volumen sin ningún reclutador.

La respuesta por defecto es una hoja de cálculo, y los datos dicen que no aguanta ni con diez veces tu tamaño. El Recruiter Nation Report 2025 de Employ (Zogby Analytics, septiembre de 2025, más de 1200 reclutadores y responsables de contratación de EE. UU.) encontró que el **79 % de los equipos de talento sigue apoyándose en hojas de cálculo para la elaboración de informes de reclutamiento**, y que el **40 % de las empresas de menos de 50 empleados depende de herramientas no especializadas**, frente al 18 % de las de 100 a 5000 empleados.

Sobre a quién conviene contratar primero, mira [el manual de las cinco primeras contrataciones](/blog/first-five-hires-seed-stage-sequencing). Sobre lo que 298 candidaturas le hacen a un proceso de revisión, mira [la crisis del triaje](/blog/300-applications-per-role-triage-crisis).

## Flujo dos: el investigador que no te encuentra y el mendigo de recompensas que ya te ha encontrado

Publicar un contacto de seguridad invita a que llegue basura. Conviene decirlo con claridad, porque es el argumento más fuerte a favor de construir un canal en lugar de exponer un buzón.

El artículo «Beg Bounties» de Troy Hunt (noviembre de 2021) documenta correos con plantilla que llegaban a **la dirección publicada en su propio `security.txt`** y que señalaban registros DMARC y cabeceras CSP ausentes: lo que Sophos describió como «configuraciones fáciles de descubrir, observables públicamente y de escasa importancia». Hunt nombra la barrera sin rodeos: **«en cuanto se publican los contactos de seguridad, las organizaciones tienen que lidiar con informes basura»**.

El hilo de Hacker News sobre ese artículo lo transmite mejor que cualquier estadística. Un comentarista, danielvf: **«Tenemos una recompensa de hasta 250 000 USD por comunicar una vulnerabilidad crítica en parte de nuestro código, además de una página entera sobre cómo notificar problemas. Nunca hemos recibido un informe importante, pero nos llegan uno o dos de SPF/DKIM/cabeceras/SSL por semana.»** Otro, tgsovlerkhgsel, resumió el coste real en una línea: **«Los mendigos de recompensas convierten en un suplicio comunicar problemas de seguridad de verdad.»** Intigriti señala que las pymes sin un programa formal son el objetivo preferido, y documenta una variante de 2025 en la que el remitente fabrica el hallazgo: sube una copia escaneada de un pasaporte a un servicio de asistencia sin autenticación, envía a VirusTotal la URL del adjunto resultante y luego lo notifica como fuga de datos y pide cobrar por ello.

El coste de no tener canal es la imagen especular. La BOD 20-01 de CISA describe el modo de fallo con las palabras del propio gobierno: **«Si quien notifica no recibe respuesta del organismo, o recibe una que considera inútil, puede dar por supuesto que el organismo no va a corregir la vulnerabilidad. Eso puede llevarle a recurrir a la divulgación pública no coordinada para forzar una corrección y proteger a los usuarios.»**

Una puerta de entrada de verdad sigue siendo rara. Un análisis de 241 millones de dominios realizado por IoT Defense encontró ficheros `security.txt` válidos en **alrededor del 0,238 %** de ellos en 2026. En la encuesta de enero de 2026 de la IoT Security Foundation, de 68 fabricantes incorporados durante 2025, **52 (76,47 %) no tenían ninguna vía de divulgación**. Las empresas nuevas son, una y otra vez, el grupo peor cubierto, que es justo el grupo que está leyendo esto.

## Tener una dirección security@ no es tener un canal de entrada

El contraejemplo más fuerte no es una empresa a la que le faltara un canal. Es una que tenía uno bueno.

Mindgard comunicó a `security-reports@cursor.com` un fallo de ejecución remota de código en Cursor (ejecución arbitraria de código mediante un `git.exe` malicioso en la raíz de un repositorio, sin interacción del usuario) el **15 de diciembre de 2025**. El **15 de enero de 2026**, el CISO de Cursor reconoció que «falló una automatización que debía enviar la invitación al programa privado de recompensas de HackerOne». Mindgard pidió novedades el 16 de febrero, el 3 de marzo, el 17 de marzo y el 1 de abril, y no obtuvo respuesta. Mindgard anunció su intención de divulgar el 1 de junio y publicó todos los detalles el **14 de julio de 2026**, siete meses después del primer contacto.

El canal existía y la dirección era correcta. Lo que falló fue la automatización del canal de entrada y el seguimiento, y una empresa bien financiada acabó con una divulgación pública igualmente. Si tu equipo es de cuatro personas, «tenemos una dirección security@» no es la respuesta. Un plazo de acuse de recibo con algo detrás, sí.

## La configuración mínima que de verdad cuenta

Puedes levantar las dos puertas de entrada en una tarde. La BOD 20-01 obliga a las agencias federales, no a tu startup, y el Reglamento europeo de Ciberresiliencia (CRA) regula productos con elementos digitales, no el SaaS puro. Trátalos como la mejor plantilla disponible, no como una obligación que estés incumpliendo ahora mismo.

1. **Monta el canal de entrada antes que la política.** La BOD 20-01 convierte la capacidad de recibir en una condición previa: tienes que poder recibir informes no solicitados antes de publicar una política. Una página a la que nadie puede enviar nada es peor que no tener página.
2. **Publica `security.txt` con `Contact` y `Expires`.** Son los dos únicos campos obligatorios de la RFC 9116. Sírvelo en `/.well-known/security.txt` por HTTPS y apunta la renovación en el calendario: el 7,3 % de los ficheros `security.txt` encontrados en 2026 ya había caducado.
3. **Apunta `Contact` a un alias, no a una persona.** En seis de las nueve empresas que encontramos, basta con que esa persona se vaya para que el canal deje de existir.
4. **Acota un sistema y luego amplía.** El modelo de la BOD 20-01 añade al menos un sistema accesible desde internet cada 90 días. Empieza por el dominio de tu producto.
5. **Separa el plazo de acuse de recibo del de resolución.** La BOD 20-01 fija como objetivo acusar recibo en 3 días hábiles y valorar la validez en 7, con la resolución como objetivo aparte a 90 días. El acuse de recibo es la promesa que puedes cumplir en la semana del lanzamiento.
6. **Permite informes anónimos y no exijas datos personales.** Ambos son requisitos firmes en la política modelo de la BOD 20-01, y el reglamento británico PSTI incluye la misma regla de no pedir información personal.
7. **Añade cláusulas de puerto seguro (Safe Harbor).** El Policymaker de disclose.io genera gratis una política, condiciones de puerto seguro, un `security.txt` y registros DNS bajo CC0, sin necesidad de cuenta. Produce un documento, no una cola de triaje, y ese es el límite honesto de la opción gratuita. Nuestra [guía de puerto seguro](/blog/safe-harbor-legal-threats-security-researchers-vdp) cubre la redacción que importa.
8. **Publica `/careers` y pon un proceso de selección detrás.** Una URL de verdad, puestos con un alcance definido y un formulario que escriba en algún sitio que no sea un buzón de correo. Si prefieres copiar un proceso antes que inventarlo, arranca desde una [plantilla de proceso de contratación](/templates).

## Por qué esto es un solo sistema y no dos compras

Pon los dos flujos uno al lado del otro y verás la misma forma operativa. Un desconocido sin autenticar te envía algo sin estructura. Hay que acusar recibo dentro de un plazo, hacer el triaje con una rúbrica, dirigirlo a una persona y cerrarlo con una decisión que tiene peso legal y reputacional. Con cuatro personas, esa forma deberías comprarla una sola vez.

El mercado no la vende así. Greenhouse no publica ningún precio, así que un fundador en fase pre-seed no puede saber cuánto le costará sin pasar por una llamada comercial. El nivel All-In-One Foundations de Ashby arranca en 400 USD al mes tanto si tu equipo es de 4 personas como si es de 90. Workable cuesta 299 USD al mes en el tramo de 1 a 20 empleados, con mensajería de texto, entrevistas en vídeo y evaluaciones como complementos de pago. El plan gratuito de Breezy permite una sola oferta activa a la vez. El propio ATS de reclutamiento de YC es bueno y gratuito, pero solo para empresas de YC, solo mientras tu condición de YC siga activa, y no hace nada por la mitad de seguridad. Un fundador de Techstars, Antler, EF o Speedrun no tiene ninguna de las dos mitades. (Más sobre [lo que cuesta a un equipo pequeño un ATS con precio por usuario](/blog/hidden-tax-per-seat-ats-pricing).)

La especificación ya defendió este argumento. La RFC 9116 coloca un campo opcional **`Hiring`** en el mismo `security.txt` que `Contact`, acotado en la sección 2.5.6 a «enlazar a los puestos de trabajo del proveedor relacionados con la seguridad». El único fichero que un investigador descarga está diseñado para llevar también tus ofertas de empleo.

Así está construido Kit. Su `security_txt_body` emite `Contact`, `Expires`, `Policy`, `Acknowledgments`, `Hiring`, `Encryption` y `Preferred-Languages` desde una sola configuración, con una caducidad por defecto de 365 días y un aviso 14 días antes de que expire. Detrás de `Contact` hay un [portal público de VDP para investigadores](/security) con una ventana de acuse de recibo configurable (72 horas por defecto), objetivos de resolución graduados por severidad, limitación de peticiones que por defecto corta a los 5 informes cada 5 minutos antes de un bloqueo temporal, y cribado con IA que marca funciones alucinadas, CVE inventados, lenguaje de plantilla y pasos de reproducción vagos. Detrás de `Hiring` hay un portal de empleo público, acceso de candidatos por enlace mágico, [plantillas de proceso](/templates) para siete categorías de puestos, ejercicios de código integrados con GitHub, revisión y votación del equipo, y programación de entrevistas. Ambos lados exponen herramientas MCP, así que un asistente de IA puede gestionar el pipeline o la cola de triaje directamente.

Conviene ser claro sobre lo que eso no compra. Kit no distribuye ofertas a portales de empleo y no calcula referencias salariales. No hace que cumplas el CRA, el PSTI ni la SOC 2; te da el canal de entrada, la política publicada, el plazo de acuse de recibo y el rastro de pruebas que esas normas dan por supuesto que ya tienes. Además, el módulo de seguridad se factura aparte del plan de contratación por usuario, así que consulta la [página de precios](/pricing) en lugar de dar por hecho que va todo en un paquete. Lo que se promete es un solo proveedor, un solo inicio de sesión y un solo `security.txt`, no un extra gratis. Y nada impide que sigan llegando mendigos de recompensas. Los límites de peticiones, el cribado y las respuestas con plantilla solo cambian lo que te cuestan, que es la parte que sí controlas.

## Qué hacer en las tres semanas previas al Demo Day

**A tres semanas:** levanta `/careers` con los dos puestos que vas a cubrir de verdad, y publica `security.txt` con `Contact` y `Expires`. Dos URL, una tarde.

**A dos semanas:** escribe la política de divulgación (alcance, pruebas permitidas, envío anónimo, sin datos personales obligatorios, puerto seguro) y los tres correos a candidatos que más vas a enviar: acuse de recibo, descarte e invitación a entrevista. En la hora 26 de un lanzamiento, las plantillas ganan a la improvisación.

**A una semana:** decide con nombre y apellidos quién se hace cargo de cada cola y qué pasa si esa persona está durmiendo. Fija tu ventana de acuse de recibo en un plazo que puedas cumplir y después prueba las dos puertas de entrada enviándote algo tú mismo.

El caso de Cursor es la razón para probarlas. Una dirección correcta con un seguimiento roto produjo el mismo resultado que no tener dirección: siete meses más tarde y en público.

Si quieres las dos colas funcionando antes del Demo Day de tu promoción, puedes [crear una cuenta de Kit](/users/sign_up) y tener el portal de empleo y el VDP en marcha esa misma tarde. Y si prefieres montártelo tú con un `security.txt` y una hoja de cálculo, adelante. La única opción que deja de funcionar el día del lanzamiento es el correo del fundador.

*Todas las mediciones de Launch YC, los sondeos de páginas de empleo, los sondeos de `security.txt` y los precios de proveedores citados en este artículo se tomaron el 13 de agosto de 2026 y cambian a diario.*