Cómo validar tu idea de software antes de programar
Lunes a la mañana. Tenés una idea que te parece obvia: "alguien tiene que resolver esto, lo necesito yo y seguro lo necesitan miles". Esa sensación de obviedad es exactamente la trampa. Antes de poner un peso en código, hay un paso que te ahorra meses y decenas de miles de dólares: validar.
Validar tu idea de software antes de programar significa conseguir señales reales de que alguien va a pagar, sin construir el producto. No es preguntarle a conocidos si "les gusta la idea"; es poner la solución hipotética frente a clientes reales y medir si dejan el mail, pagan una seña o firman una carta de intención. Importa porque, según CB Insights, el 42% de las startups fracasan porque no había mercado para el producto. Validar es la forma más barata de no entrar en esa estadística.
Lo escribo desde el lado del que construye. Soy founder técnico y la conversación más difícil que tengo es decirle a alguien entusiasmado "antes de que te cobre por programar esto, validemos que alguien lo quiere". Casi nadie quiere escucharlo. Los que lo escuchan se ahorran una fortuna.
Por qué validar primero te ahorra una fortuna
Validar antes de construir invierte el orden caro por el orden inteligente. El instinto dice "lo construyo bien y después lo vendo". Pero si gastás tres meses y USD 40.000 programando para recién ahí descubrir que nadie lo quería, aprendiste tarde y caro lo que podías saber en dos semanas hablando con diez personas.
Los números lo confirman. En su revisión de 2024 sobre 431 empresas, CB Insights encontró que el 43% murió por mal product-market fit, y aunque el 70% "se quedó sin capital", eso es el síntoma final, no la causa. La causa es haber invertido el capital en construir antes de saber si había demanda. Sobre cómo una idea puede ser correcta pero demasiado grande para arrancar, escribí cómo detectar una idea de SaaS demasiado grande.
Validar no es ser cauteloso de menos. Es la forma más cauta de gastar tu plata: descubrís barato lo que de otro modo descubrirías carísimo.
Las cinco formas de validar, de la más barata a la más cara
Hay un menú de tácticas ordenadas por esfuerzo. Empezá por arriba y bajá solo si las señales son buenas.
| Método | Esfuerzo | Qué mide | Costo |
|---|---|---|---|
| Entrevistas de problema | Bajo | ¿El dolor es real y urgente? | 0 |
| Landing + lista de espera | Bajo | ¿Hay interés suficiente? | 1 día |
| Pre-venta | Medio | ¿Pagan antes de que exista? | 1 semana |
| Concierge (a mano) | Medio | ¿El valor entregado sirve? | 2-3 semanas |
| Prototipo no-code | Alto | ¿Cómo lo usan de verdad? | 2-4 semanas |
La regla de oro: cada paso tiene que darte permiso para el siguiente. Si nadie deja el mail en la landing, no construyas el prototipo. Si nadie paga la pre-venta, no contrates un dev. Cada "no" temprano es plata que no quemaste. El detalle de cómo construir después está en cómo construir un MVP siendo no técnico.
Cómo hacer entrevistas de problema que sirvan
Una buena entrevista de validación habla del problema del cliente, no de tu solución. El error número uno es ir a "venderles" tu idea. Si hablás más vos que ellos, lo estás haciendo mal. Tu trabajo es callarte y entender qué hacen hoy para resolver ese dolor.
Tres preguntas que valen oro:
- ¿Cuándo fue la última vez que tuviste este problema? Si no se acuerdan, el dolor no es urgente.
- ¿Qué hacés hoy para resolverlo? Si ya pagan por algo, hay mercado. Si lo ignoran, no.
- ¿Cuánto te cuesta no resolverlo? Si no pueden ponerle un número, no van a pagar por arreglarlo.
Si después de diez entrevistas el patrón es "sí, me pasa, pero no es para tanto", tenés un problema tibio, y los problemas tibios no se pagan. Mejor saberlo ahora. El lado humano de aprender esto en carne propia lo conté en el error de producto de los founders técnicos.
La pre-venta: la validación que no miente
La pre-venta es la única validación que no te puede mentir, porque involucra dinero real. Una persona puede decirte que tu idea es genial por cortesía, dejar el mail por curiosidad y nunca volver. Pero si saca la tarjeta y paga una seña antes de que el producto exista, ahí tenés la señal más honesta del mercado.
No necesitás el producto terminado para pre-vender. Necesitás una promesa clara, un precio y una forma de cobrar. "Estoy construyendo X, sale Y, si reservás ahora tenés Z de descuento y sos de los primeros en usarlo." Si cinco personas pagan, validaste mejor que con cien encuestas. El mercado no-code llegará a USD 52.000 millones en 2026 justamente porque hoy podés montar una página de pre-venta en una tarde, sin programar.
Cinco pre-ventas valen más que mil "me encanta tu idea". El dinero es el único voto que cuenta.
Los tres errores que arruinan una validación
Validar mal es casi peor que no validar, porque te da falsa confianza. Estos son los tres errores que veo una y otra vez.
El primero es preguntarle a la gente equivocada. Tu familia, tus amigos y tu socio te van a decir que sí por afecto, no por mercado. La validación solo cuenta si viene de tu cliente ideal real: alguien que tiene el problema, el presupuesto y la autoridad para pagar. Diez conversaciones con clientes reales valen más que cien con tu círculo.
El segundo es escuchar palabras en vez de mirar acciones. "Me encanta", "lo usaría", "qué buena idea" son ruido. Lo que cuenta es qué hace la persona: ¿dejó el mail? ¿pagó la seña? ¿te presentó a alguien? Las acciones con costo no mienten; las opiniones gratis, sí. Por eso la pre-venta es tan poderosa.
El tercero es validar la solución antes que el problema. Si arrancás mostrando tu app, sesgás todo: la gente reacciona a tu idea en vez de contarte su realidad. Primero confirmá que el problema duele y es urgente; recién después probá si tu solución lo resuelve mejor que lo que ya usan. El 29% de las startups que cierran lo hacen por mal timing, y validar el problema temprano te dice si el mercado está listo o todavía no.
Qué hacer con los resultados
Lo que medís decide tu próximo movimiento. Si las señales son fuertes (gente que paga o deja el mail con ganas), avanzás a construir el MVP mínimo. Si son tibias, no las fuerces: iterá el problema o el segmento antes de tocar código. Y si son nulas después de un esfuerzo honesto, soltá esa versión de la idea sin culpa: acabás de ahorrarte meses y dinero.
El objetivo de validar no es confirmar que tenías razón. Es descubrir la verdad lo más barato posible. Si validar te dice que no, ganó tu cuenta bancaria. Para entender el panorama completo, de la validación al primer cliente que paga, está tenés la idea, no el código: cómo construir tu SaaS.
Preguntas frecuentes
¿Cuánto tiempo lleva validar una idea de software?
Una validación honesta lleva de dos a cuatro semanas: unas diez entrevistas de problema, una landing con lista de espera y, si las señales son buenas, una pre-venta. No necesitás más. Si después de un mes de esfuerzo real nadie paga ni deja el mail, esa es tu respuesta, y llegó barata.
¿Puedo validar sin gastar nada de dinero?
En gran parte, sí. Las entrevistas de problema cuestan cero y son el método más valioso. Una landing simple cuesta casi nada. La pre-venta no requiere construir el producto. El gasto real recién aparece cuando las señales son lo bastante fuertes como para justificar el MVP, y para entonces ya sabés que vale la pena.
¿Qué pasa si valido y nadie está interesado?
Es el mejor resultado posible a esa altura. Acabás de descubrir, por unos cientos de dólares y unas semanas, lo que de otro modo te habría costado USD 40.000 y tres meses. Iterá el problema o el segmento; muchas ideas ganadoras son la segunda o tercera versión de una idea original que no validó.
¿Las encuestas sirven para validar?
Poco. Las encuestas miden opiniones, y las opiniones son gratis: la gente dice que algo le gusta sin compromiso. Validan mucho mejor las acciones con costo: dejar un mail, pagar una seña, firmar una carta de intención. Si tenés que elegir, una pre-venta de cinco personas vale más que cien encuestas respondidas.
¿Necesito un prototipo para validar?
No siempre. Las primeras y más baratas formas de validar (entrevistas, landing, pre-venta) no requieren prototipo. Un prototipo no-code conviene recién cuando ya confirmaste interés y querés ver cómo la gente usaría el producto de verdad. Construir el prototipo antes de tener señales es invertir el orden y gastar de más.