Hay un tipo de hito que no aparece en ningún changelog: el día en que tu sistema deja de construir para ti y construye para alguien más. Ayer, Olave Ruiz Corporation corrió su pipeline completo para un tercero por primera vez — un contacto real, con un problema real de prospección. Hoy la propuesta quedó publicada en producción, detrás de una clave de ocho dígitos. Y el correo ya salió.

El problema que llegó por la puerta

Una organización — su nombre queda confidencial a propósito; es la regla número uno del proyecto — capta prospectos por WhatsApp, Messenger e Instagram: mensajes directos y comentarios en publicaciones. Tres puertas distintas, un CRM que vive en otra parte, y un equipo que responde en el orden en que puede, no en el orden en que debería. Los prospectos que más necesitan respuesta esperan lo mismo que los demás. Algunos se van.

La primera hipótesis era razonable: configurar una mesa de ayuda existente y adaptarla. El cliente la descartó antes que nosotros, y con buenos argumentos: esas herramientas están diseñadas para resolver casos de clientes existentes, no para captar prospectos nuevos, y adaptarlas significa acumular deuda en un lenguaje de scripting ajeno. The Oracle corrió la investigación de nuevo con ese input y el veredicto cambió: construir una app propia. Riesgo técnico 58/100. CONSTRUIR.

Un funnel completo sin tocar mi escritorio

La sesión de ayer fue remota — yo lejos del teclado de siempre, la corporación corriendo en la nube. Pepper ruteó la consulta al pipeline de producto. Wags evaluó y aprobó con condiciones (la más importante: las respuestas a prospectos son siempre humanas; la IA prioriza, jamás contesta). The Oracle investigó dos veces — la segunda para validar el pivote. Saul le puso nombre de trabajo: Pulso. Steve escribió el PRD. Ive entregó la spec de diseño de la bandeja omnicanal, mobile-first. Cinco commits en una rama, esperándome.

Hasta ahí, un buen día de pipeline. Lo que me interesa contar viene después.

La propuesta también es producto

Con el funnel listo quedaba el paso más viejo del oficio: mandarle la propuesta al cliente. Lo normal habría sido un PDF adjunto. En cambio, la corporación construyó /customers/pulso: dos páginas vivas en el sitio — una ejecutiva, para que el destinatario la presente a otros; una técnica, para quien quiera mirar debajo del capó — detrás de una clave de ocho dígitos que viaja por un canal aparte.

Y el candado no es decorativo. La clave se compara en tiempo constante, para no filtrar información ni por milisegundos. Hay un límite de ocho intentos por minuto por IP — holgado para un humano, letal para un script frente a cien millones de combinaciones. La sesión es una cookie firmada que expira en ocho horas. Y el sistema es fail-closed: si falta configuración, no entra nadie. La clave no existe en el repositorio; vive únicamente como variable de entorno en producción.

Verificar antes de enviar

La sesión de hoy fue aterrizar todo eso: merge a main, variables de entorno en Vercel (por API REST — una lección vieja de esta corporación: el CLI guarda comillas literales cuando le pasas secretos por stdin), deploy, y la parte que no se negocia: verificar en producción antes de que el destinatario tenga el link. Clave errada: 401. Clave correcta: cookie y contenido. Sin sesión: solo el formulario. Recién entonces salió el correo.

En esa verificación casi me tropiezo con algo que vale la pena contar. Las páginas gateadas devuelven 200 sin clave — y mi primer reflejo fue “fuga”. No lo era: la misma URL decide qué renderizar, formulario o propuesta, y un test de códigos de estado habría dado una falsa alarma. Hubo que leer el HTML: sin sesión no hay ni una palabra de la propuesta en el cuerpo; con sesión, está completa. Es la misma lección del chronicle pasado, acumulando intereses: los códigos de estado no cuentan la historia; el cuerpo sí. Y un detalle más que aprendimos a revisar a porrazos: confirmar que el CDN no cachee la versión desbloqueada.

Por qué importa

Dos cosas. La primera: ORC nació para construir productos propios y documentarlo en público. Esta es la primera vez que el pipeline completo — intake, viabilidad, marca, PRD, diseño — produce para un cliente externo potencial. Si Pulso avanza, será el primer producto de la corporación nacido de un problema ajeno.

La segunda es más sutil: tratar una propuesta comercial con los mismos gates de ingeniería que un feature cambia la naturaleza del documento. Una propuesta que vive en el navegador, gateada, verificada en producción, dice más del equipo que la escribió que cualquier slide. El gate es la demo.

Qué viene

Ahora, esperar la respuesta. Si hay GO, la instrucción de Wags es clara: la verificación de negocio de Meta — el verdadero cuello de botella, semanas de trámite — se inicia el día cero, y la Fase 1 parte por WhatsApp. Mientras tanto, la propuesta espera tras su clave. Ocho dígitos entre un problema real y su producto.