Matt Senter
ahoraproyectossobre mícontactoblog

← Blog

¿Ha muerto la lista de espera?

Cuando las apps se lanzan más rápido, hacer esperar a los clientes necesita una razón mejor.

10 de noviembre de 2026 · Matt Senter

Una fila vacía delimitada por cuerdas de terciopelo lleva a una puerta cerrada; un cliente camina hacia un taller abierto donde se usan objetos luminosos con forma de app.

Anuncias una app. Creas una página. Recoges correos. Prometes que viene algo emocionante.

Mientras tanto, otra persona ve la misma oportunidad, abre un agente de programación y empieza a construir.

Cuando envías el correo de «Ya casi estamos», tus posibles clientes quizá ya estén usando otra cosa.

Ese es mi problema con las listas de espera en la era del desarrollo con agentes. El tiempo entre una idea y una versión útil ha cambiado. No estoy tan convencido de que los consejos sobre lanzamientos se hayan adaptado.

Si puedes ofrecer algo útil hoy, ¿por qué pedir que vuelvan después?

El método anterior tenía una razón

Cuando crear un producto requería meses de ingeniería, una lista de espera permitía aprovechar el interés inicial. Servía para probar mensajes, reclutar usuarios beta y reunir una audiencia mientras el software tomaba forma.

Linear y Superhuman son ejemplos conocidos. Linear elegía usuarios de una lista e iteraba con pequeños grupos. Superhuman invertía mucho en la incorporación personal. Ambos métodos ayudaban a aprender de los clientes.

Pero esas estrategias nacieron antes de los agentes de programación actuales. Explican el origen del método; no demuestran que sus ventajas y costes sigan siendo los mismos.

Cuando baja el coste de entregar un experimento funcional, pierde fuerza la justificación para recoger únicamente muestras de interés.

Un correo indica que a alguien le gustó tu promesa lo suficiente como para rellenar un formulario. Una persona usando tu app puede señalar dónde falla esa promesa.

También das tiempo a la competencia

Una lista pública anuncia una oportunidad antes de que necesariamente hayas conseguido un cliente.

Esto importa especialmente cuando la función principal del producto es relativamente fácil de reproducir. El anuncio describe el problema, la demo muestra la solución y el número de inscritos revela interés.

Un competidor no necesita copiar toda tu hoja de ruta. Basta con resolver suficiente del problema del cliente para resultar útil antes.

Es un riesgo competitivo, no una ley demostrada. No he encontrado estudios que prueben que las listas hacen perder mercados habitualmente. Tampoco lanzar primero garantiza ganar.

Aun así, prolongar deliberadamente el intervalo entre «Lo quiero» y «Puedo usarlo» merece una revisión.

El problema del cliente existe ahora. El calendario de lanzamiento es tuyo.

¿Qué nos dicen los ejemplos recientes?

En su retrospectiva, Lovable describe dos lanzamientos fallidos en 2024, incorporaciones graduales desde una lista y una IA que se atascaba demasiado. Atribuye el despegue a mejoras del producto, un cambio de marca y una comunicación mejor. La lista existía antes; no bastó para producir ese resultado.

Manus complica la afirmación de que los lanzamientos restringidos han muerto. Comenzó las pruebas por invitación en marzo de 2025 y después declaró 100 millones de dólares de ingresos recurrentes anuales. Eso demuestra éxito comercial tras un lanzamiento restringido. No demuestra que restringir el acceso lo causara ni que abrir antes hubiera funcionado peor.

El criterio debe ser el mismo en ambos sentidos. Que una empresa con lista triunfe no prueba que la lista funcionara. Que fracase no prueba que la lista fuera el problema.

Invitar a alguien a un producto es diferente

Hay una diferencia importante entre recoger interés en una idea y controlar el acceso a algo que ya se usa.

Instinct ilustra el modelo de invitación: su página pública incluye un enlace para invitar a un amigo. Eso no explica por qué limita el acceso, pero apunta a otra interacción: un usuario puede incorporar a otra persona a la experiencia.

Me parece más creíble cuando la invitación lleva a un producto que funciona.

Existen límites razonables. Quizá solo puedas atender a unos pocos clientes nuevos por semana. El uso de agentes puede ser caro. Tal vez necesites observar fallos antes de admitir a más personas.

Las invitaciones también pueden fabricar escasez. El mecanismo no resuelve la cuestión; la razón de la restricción sí.

La mejor defensa: encontrar clientes sigue costando trabajo

Desarrollar más rápido no crea distribución automáticamente.

Un relato reciente lo ilustra. El fundador de Hado SEO declaró haber recogido 80 correos y convertido cinco en clientes de pago durante la semana de lanzamiento. Antes había ayudado a posibles clientes en comunidades y afinado la oferta. Son resultados declarados por el propio fundador, pero hablan de conversión, no solo de inscripciones.

Es un argumento legítimo para una preparación breve. Puedes averiguar dónde se reúnen los clientes, cómo describen el problema y si puedes llegar a ellos.

Pero queda una pregunta: ¿aprenderías más entregándoles un producto pequeño que funcione?

Cuanto más rápido se construye, más viable resulta esa alternativa.

Que la espera se justifique

Desconfío de las listas cuyo objetivo principal es hacer deseable una app que aún no se ha publicado.

Una lista útil debería responder a algo concreto: capacidad limitada, un experimento con clientes, una dependencia o una limitación del producto que estás resolviendo. Debe haber una razón para esperar y una condición para entrar.

«Crear expectación» es una respuesta mucho más débil.

Antes de añadir el formulario, piensa qué podrías entregarles. Un flujo de trabajo. Una función útil. Una versión limitada que haga algo bien.

Entonces podrás medir si la usan, si vuelven y si les importan las mejoras.

Si alguien puede lanzar una versión útil de tu idea antes de que termines de crear expectación, ¿qué estás esperando exactamente?

Matt Senter

Matt Senter

Founder, entrepreneur, and CEO based in Durham, NC, with 30 years building software and 18 companies and products founded. Currently Founder & CEO of Senternet and Co-Founder, COO, and CTO of BeeReady, and the builder behind Orgabot, Highwire, StockCar, Premail, Comoji, Burly, and Weatherling. More about Matt · Get in touch.

En esta página

  • El método anterior tenía una razón
  • También das tiempo a la competencia
  • ¿Qué nos dicen los ejemplos recientes?
  • Invitar a alguien a un producto es diferente
  • La mejor defensa: encontrar clientes sigue costando trabajo
  • Que la espera se justifique

Sigue leyendo

  • Cómo evitar las «granadas de slop»La salida de IA sin revisar genera trabajo para los demás. Evitar las granadas de slop es un problema de gestión: ingenieros senior y revisión real.
  • La era post-IDEPor qué cancelé JetBrains y dejé atrás el IDE: el lenguaje natural y la orquestación de agentes son ya mi interfaz principal para programar.
  • La evolución de la automatización: de scripts de shell a organizaciones de IALa automatización sigue subiendo de nivel, desde scripts e infraestructura como código hasta organizaciones de IA coordinadas.

Más sobre Desarrollo asistido por IA →

© 2026 Matt Senter · Creado por Matt Senter de SenternetHecho con OrgabotDurham, Carolina del NorteCreado para quienes construyensobre míblogHerramientasPrivacidadTérminos
EnglishEspañol简体中文Français日本語PortuguêsDeutsch