Cómo validar una idea de SaaS antes de escribir una sola línea de código

La mayoría de los productos SaaS fallidos no fracasaron porque el código fuera malo. Fracasaron porque nadie quería pagar por lo que los fundadores construyeron. La validación es el trabajo que haces antes de escribir una sola línea de código para asegurarte de que no estás a punto de dedicar seis meses a un producto bellamente diseñado que resuelve un problema demasiado pequeño, demasiado raro o demasiado barato como para sostener un negocio.

La buena noticia es que una idea SaaS se puede validar en tres a cinco semanas por menos de trescientos dólares. La mala noticia es que la mayoría de los fundadores se saltan este paso porque construir se siente como progreso y hablar con desconocidos se siente como retraso. El orden importa — cada semana de validación ahorra aproximadamente un mes de construcción desperdiciada más adelante.

Empieza con una frase, no con una lista de funciones

Antes que nada, escribe una frase con esta estructura: 'Ayudo a [rol específico] en [tipo específico de empresa] a [tarea específica] para que puedan [resultado específico].' Versión mala: 'Ayudo a las pequeñas empresas a ahorrar tiempo en operaciones.' Versión buena: 'Ayudo a los responsables de operaciones en agencias de tres a veinte personas a conciliar el control horario con las facturas de clientes para que puedan facturar semanalmente en lugar de mensualmente.'

Si no puedes escribir esa frase, aún no estás listo para validar — tienes una idea sobre una categoría, no una idea sobre un cliente. Cuanto más concreta sea la frase, más fáciles serán todos los pasos posteriores: sabrás exactamente a quién entrevistar, exactamente qué foros leer y exactamente a qué audiencia de anuncios dirigirte.

Haz de diez a quince entrevistas sobre el problema

Encuentra de diez a quince personas que encajen con esa frase y pregúntales por el problema, no por tu solución. El objetivo es aprender cómo describen el dolor, por qué ya pagan y qué han probado. Tres preguntas hacen la mayor parte del trabajo: 'Cuéntame la última vez que hiciste esta tarea. ¿Qué usaste? ¿Qué fue molesto?' Escucha señales de gasto. Si la persona ya paga por hojas de cálculo, contratistas o una herramienta torpe, el problema es real. Si se encoge de hombros, no lo es.

Conseguir esas entrevistas en sí mismo es una señal de validación. Si no puedes conseguir quince reuniones a partir de cien mensajes de LinkedIn o correos en frío dirigidos, tu cliente es difícil de alcanzar — y un negocio SaaS es en gran medida un negocio de adquisición de clientes. Ese hallazgo vale más que las entrevistas en sí mismas.

Crea una landing page, no un producto

Describe el producto en una sola página como si ya existiera. Muestra el resultado, indica un precio y pon un botón que diga 'Get Early Access' o 'Start Free Trial.' Usa una herramienta que ya conozcas — Carrd, Framer, Webflow o una página sencilla de Next.js. La página debería llevar un día, no una semana.

Invierte entre cien y doscientos dólares en anuncios muy segmentados — LinkedIn para roles B2B, Reddit o newsletters de nicho para audiencias prosumidoras, Google Search para palabras clave con alta intención como 'reconcile time tracking with invoices.' Lleva el tráfico a tu página y mide dos cosas: el porcentaje de clics al llamado a la acción y el porcentaje de visitantes que dejan su correo electrónico.

• Por debajo del uno por ciento de captación de correo en tráfico muy segmentado: el mensaje o la audiencia están mal.
• Entre dos y cinco por ciento: una señal real — sigue iterando en el texto y la audiencia.
• Por encima del cinco por ciento con más de cien visitantes: señal sólida, pasa a un piloto de pago.
• Incluye siempre un precio o un rango de precios — una tarificación vaga infla las altas y destruye la señal.

Lanza un piloto tipo concierge o Wizard-of-Oz

Toma a las primeras cinco o diez personas que se registraron y ofréceles el resultado a un precio real — entre cincuenta y doscientos dólares al mes está bien — pero entrégalo manualmente entre bastidores. Usa hojas de cálculo, Zapier y tus propias manos para producir el resultado. El cliente nunca ve las costuras; tú aprendes exactamente lo que el producto necesita hacer y obtienes ingresos reales.

Si cinco desconocidos no pagan ni una pequeña cantidad por una versión entregada manualmente del resultado, ningún software pulido cambiará eso. Si sí pagan, ahora tienes clientes de pago, un flujo de trabajo documentado y una especificación de producto mucho mejor que cualquier documento que pudieras haber escrito de antemano.

Números que significan 'adelante', 'tal vez' y 'no'

La validación se juzga por patrones, no por puntos de datos aislados. Después de tres a cinco semanas de trabajo, mira el panorama combinado: lo fácil que fue concertar entrevistas, lo claramente que la gente describió el dolor con sus propias palabras, lo bien que convirtió la landing page y cuántas personas pagaron por el piloto manual. Empareja la evidencia con uno de tres resultados y actúa en consecuencia — negarte a decidir es, en sí mismo, una decisión de seguir quemando tiempo.

• Adelante: las entrevistas fueron fáciles, tres o más personas pagaron por adelantado o firmaron cartas de intención, y la conversión fue fuerte.
• Tal vez: existe interés pero no se movió dinero — acota el cliente, sube el precio o afina el resultado y vuelve a probar.
• No: difícil encontrar al cliente, dolor vago, sin pago pese a múltiples intentos. Detente y elige un problema más concreto.

Cuando finalmente estés listo para construir

Estás listo para escribir código cuando la única pregunta que quede sea si puedes construir bien el producto, no si alguien lo quiere. Para entonces deberías conocer exactamente el trabajo que hay que hacer, el precio que el cliente acepta, el canal por el que llega y el flujo de trabajo que pretendes automatizar. Construye la versión más pequeña que entregue el resultado prometido a los primeros diez clientes de pago, y sigue entregando el resto manualmente hasta que el producto alcance el nivel necesario.

La validación no elimina el riesgo; lo traslada de '¿a alguien le importará?' — la pregunta que mata a la mayoría de las empresas SaaS — a '¿podemos ejecutar?' — la pregunta a la que los fundadores suelen estar mejor preparados para responder. Ese intercambio es justamente el motivo de hacer el trabajo antes de lanzar una sola línea de código.