Cómo decidir si una idea vale la pena antes de empezar a programar

Tener ideas no es el problema. El problema es abrir el editor demasiado pronto.

Hoy es más fácil que nunca convertir una idea en una primera versión: Claude Code, Cursor, Lovable, Replit, v0, n8n y decenas de herramientas pueden acelerar muchísimo la construcción. Pero esa velocidad trae una trampa: ahora puedes perder una semana construyendo algo que antes te habría llevado un mes. Es mejor, sí. Pero sigue siendo una semana perdida si la idea nunca tuvo usuario, dolor, demanda o canal.

La pregunta importante no es “¿puedo construir esto?”. Con IA, muchas veces la respuesta es sí.

La pregunta es: ¿esta idea merece que la construya ahora?

Esta guía te da un filtro práctico para decidirlo antes de empezar a programar. Está pensada para founders técnicos, solopreneurs y builders que tienen una lista infinita de ideas en Notion, Apple Notes o WhatsApp, pero necesitan una forma más fría de elegir qué merece pasar a código.

La tesis central es simple:

Una idea vale la pena cuando puedes describir con precisión quién la necesita, qué dolor urgente resuelve, cómo encontrarás a los primeros usuarios y cuál es la versión mínima que puedes entregar en una semana.

Si no puedes responder eso, no tienes una idea lista para construir. Tienes material para investigar.

El error: confundir claridad con demanda

Un post reciente en r/SaaS planteaba un problema muy común: el autor tenía unas 40 ideas guardadas y antes elegía la que más le emocionaba ese día. El resultado: enviaba quizá 1 de cada 20.

Para corregirlo, empezó a usar tres filtros antes de abrir Claude Code:

¿Puedo describir el usuario en una frase sin decir “personas que…”?
¿Puedo describir el problema en una frase sin usar “y”?
¿Existe una versión suficientemente pequeña para enviarla en una semana?

Además, metía la idea en una herramienta de generación de PRD para ver si la especificación salía coherente. Si la especificación era vaga, la idea todavía no estaba formada.

Ese filtro es bueno, pero incompleto.

La comunidad apuntó el matiz clave: claridad no es demanda.

Que puedas explicar una idea con claridad no significa que alguien la quiera. Tampoco significa que el problema sea urgente, que alguien pague por resolverlo, o que tengas una forma viable de llegar a los primeros usuarios.

Una idea puede sonar perfecta en una especificación y seguir siendo inútil en el mercado.

Por eso el proceso correcto tiene dos capas:

Claridad interna: ¿entiendes qué quieres construir, para quién y con qué alcance?
Señal externa: ¿hay personas reales que ya sienten ese dolor, buscan soluciones o pagan con tiempo/dinero para resolverlo?

Las herramientas de IA ayudan con la primera capa. No reemplazan la segunda.

El filtro de 7 pasos antes de programar

Usa este proceso como una compuerta. No es burocracia. Es una forma de evitar construir por impulso.

1. Escribe el usuario sin esconderte detrás de “personas que”

Una idea débil suele empezar así:

“Una app para personas que quieren ser más productivas.”
“Una herramienta para negocios que usan IA.”
“Un dashboard para equipos que necesitan organizarse mejor.”

El problema con esas frases es que parecen específicas, pero no lo son. “Personas que quieren ser más productivas” puede significar estudiantes, abogados, founders, vendedores, freelancers, equipos de soporte o creadores de contenido. Cada grupo tiene dolores, presupuestos, canales y urgencias distintas.

Una mejor frase identifica un perfil concreto:

“Dueños de academias online que venden por WhatsApp y pierden leads porque responden tarde.”
“Agencias pequeñas que gestionan reporting mensual en hojas de cálculo para 10-30 clientes.”
“Consultores B2B que reciben llamadas de discovery pero no convierten notas en propuestas a tiempo.”

La regla práctica:

Si no puedes nombrar 3-5 personas reales que encajan con el usuario, probablemente el usuario todavía es imaginario.

No tienen que ser clientes confirmados. Pero sí humanos concretos: alguien que conoces, alguien con quien hablaste, alguien que viste quejarse en una comunidad, alguien que publicó una workaround.

Si solo puedes describir una “persona ideal” en abstracto, todavía estás en fantasía estratégica.

2. Define el problema en una frase sin meter tres problemas juntos

Otra señal de idea inmadura es el problema compuesto:

“Ayuda a emprendedores a organizar tareas, automatizar seguimiento y mejorar ventas.”
“Permite a restaurantes gestionar reservas, promociones y atención al cliente.”
“Automatiza contenido, análisis y distribución para creadores.”

Eso no es un problema. Es una lista de deseos.

Para validar, necesitas una frase con un dolor principal:

“Pierden leads porque responden consultas de WhatsApp varias horas tarde.”
“Tardan 6 horas al mes copiando métricas de campañas a un reporte manual.”
“Olvidan hacer seguimiento después de llamadas de venta y pierden oportunidades calientes.”

Una buena frase de problema tiene tres características:

Es observable: puedes ver el comportamiento o la consecuencia.
Tiene costo: tiempo, dinero, riesgo, reputación o ansiedad.
No depende de tu solución: el problema existe aunque tu producto no exista.

Si necesitas explicar tu solución para que el problema suene importante, probablemente todavía no entendiste el dolor.

3. Pregunta “¿por qué ahora?”

Una idea puede ser buena y aun así no ser urgente.

La pregunta “¿por qué ahora?” separa problemas latentes de problemas activos. No basta con que alguien tenga un dolor. Necesitas entender por qué ese dolor se volvió suficientemente importante hoy.

Buenas respuestas:

“Está recibiendo más leads de los que puede responder manualmente.”
“El costo de adquisición subió y ya no puede permitirse perder oportunidades.”
“Contrató equipo y el proceso informal empezó a romperse.”
“Un cambio de plataforma/regulación/mercado hizo que el método anterior dejara de funcionar.”
“La IA bajó el costo técnico y ahora algo que antes era caro se puede hacer en días.”

Malas respuestas:

“Porque la IA está de moda.”
“Porque sería útil.”
“Porque nadie lo hizo bien.”
“Porque yo lo usaría algún día.”

“Algún día” mata productos. Las buenas ideas tempranas suelen vivir cerca de dolores que ya están generando fricción esta semana.

4. Busca evidencia de que ya pagan con tiempo, dinero o vergüenza

No empieces preguntando “¿pagarías por esto?”. La gente suele responder de forma educada, optimista o imaginaria.

Observa qué hacen hoy.

Señales fuertes de demanda:

Pagan por una herramienta imperfecta.
Contratan a alguien para hacerlo manualmente.
Usan hojas de cálculo, Zapier, n8n, Airtable o scripts frágiles para resolverlo.
Preguntan en comunidades “¿hay alguna herramienta que haga X?”.
Comparten quejas repetidas con el mismo lenguaje.
Tienen un proceso manual doloroso, pero lo siguen haciendo porque el resultado importa.

Señales débiles:

Dicen “interesante”.
Le dan like a un post.
Se apuntan a una waitlist sin contexto.
Amigos dicen que la idea suena buena.
Un modelo de IA genera un PRD bonito.

Una regla útil:

Si nadie está pagando por resolver el problema, busca al menos evidencia de que ya está pagando con tiempo, esfuerzo o riesgo.

En negocios pequeños, esto aparece mucho como “soluciones parche”: Google Sheets enormes, audios de WhatsApp, asistentes virtuales, formularios conectados a mano, reportes mensuales copiados desde cinco plataformas, etc.

Ahí suele haber oportunidad, porque no estás inventando el dolor. Estás reemplazando una workaround.

5. Encuentra el canal antes de construir

Muchos builders validan el producto, pero no validan la distribución.

Antes de programar, responde:

¿Dónde viven estas personas?
¿Qué comunidades leen?
¿Qué buscan en Google o YouTube?
¿A quién siguen?
¿Qué palabras usan para describir el problema?
¿Cómo conseguiría los primeros 10 usuarios si tuviera que hacerlo esta semana?

Si no puedes encontrar 10 usuarios potenciales, no estás listo para construir. Estás listo para investigar.

Esto no significa que necesitas una estrategia de growth completa. Solo necesitas una ruta inicial creíble.

Ejemplos:

“Voy a contactar a 20 dueños de academias que ya venden por WhatsApp y ofrecerles revisar su flujo de leads.”
“Voy a publicar una checklist en un grupo de agencias y pedir ejemplos de reporting manual.”
“Voy a buscar en Reddit, LinkedIn y grupos de Slack frases como ‘manual reporting’, ‘WhatsApp leads’, ‘forgot to follow up’ y recopilar quejas reales.”

La distribución temprana empieza como trabajo manual. Si no sabes dónde hacer ese trabajo manual, construir más features no lo va a arreglar.

6. Reduce el alcance a una versión de una semana

La regla de “enviarlo en una semana” es brutalmente útil porque obliga a cortar fantasía.

No preguntes: “¿Cuál es el producto ideal?”.

Pregunta:

¿Cuál es la versión más pequeña que entrega un resultado real a una persona real en 7 días?

Ejemplos:

No construyas “CRM con IA para WhatsApp”. Construye “captura automática de leads de WhatsApp en una hoja con recordatorio de seguimiento”.
No construyas “plataforma de reporting para agencias”. Construye “generador de reporte mensual desde una plantilla y 3 métricas clave”.
No construyas “asistente completo para propuestas comerciales”. Construye “convierte notas de discovery en un primer borrador de propuesta”.

La versión de una semana no tiene que escalar. Tiene que confirmar si el dolor existe y si el resultado importa.

YC suele insistir en hablar con usuarios, lanzar rápido y usar el MVP como proceso de aprendizaje, no como producto final. Esa idea es especialmente importante ahora: con IA puedes construir rápido, pero el objetivo del MVP no es demostrar que sabes construir. Es descubrir si alguien quiere el resultado.

7. Usa IA para tensionar la idea, no para autoengañarte

Una herramienta de IA puede ayudarte a detectar vaguedad:

Pídele que escriba el usuario objetivo.
Pídele que defina el problema en una frase.
Pídele que proponga un MVP de una semana.
Pídele que identifique supuestos no validados.
Pídele que genere preguntas para entrevistas.

Pero cuidado: los modelos son muy buenos convirtiendo ideas vagas en documentos convincentes.

Un PRD bonito puede hacer que una idea parezca más madura de lo que está. La prueba no es si la IA puede escribir una especificación. La prueba es si esa especificación se conecta con evidencia real.

Usa este prompt como filtro:

Actúa como un evaluador brutal de ideas SaaS.

Idea: [describe la idea]
Usuario objetivo: [una frase]
Problema: [una frase]
Evidencia observada: [quejas, workarounds, pagos, entrevistas]
Canal inicial: [dónde encontraré los primeros 10 usuarios]
MVP de 7 días: [qué construiré]

Evalúa:
1. Qué parte está clara.
2. Qué parte es suposición.
3. Qué evidencia falta antes de programar.
4. Qué versión más pequeña podría probarse esta semana.
5. Señales que indicarían matar la idea.

No seas amable. Busca debilidades.

Si el modelo responde con demasiada seguridad pero tú no tienes evidencia externa, no avances. Vuelve a hablar con usuarios.

Scorecard: decide construir, investigar o matar

Antes de abrir el editor, puntúa la idea del 0 al 2 en cada dimensión.

1. Usuario específico

0: “personas que…” / segmento demasiado amplio.
1: segmento claro, pero sin personas reales identificadas.
2: segmento claro + 3-5 personas reales o comunidades concretas.

2. Dolor observable

0: beneficio genérico o aspiracional.
1: problema claro, pero sin costo visible.
2: problema con costo evidente en tiempo, dinero, riesgo o estrés.

3. Urgencia / “por qué ahora”

0: sería útil algún día.
1: hay interés, pero no urgencia.
2: hay presión actual para resolverlo.

4. Evidencia de comportamiento

0: solo opiniones o entusiasmo.
1: algunas quejas o señales débiles.
2: workarounds, pagos, búsquedas activas o procesos manuales repetidos.

5. Canal inicial

0: no sabes dónde encontrar usuarios.
1: tienes una hipótesis de canal.
2: sabes exactamente dónde contactar o observar a los primeros 10 usuarios.

6. MVP de una semana

0: requiere construir una plataforma completa.
1: se puede reducir, pero aún está grande.
2: hay una prueba funcional entregable en 7 días.

7. Riesgo técnico controlado

0: lo más difícil es tecnología incierta.
1: hay una parte técnica dudosa.
2: la tecnología es viable; el riesgo principal es demanda.

Interpretación:

0-6 puntos: no programes. Reformula o mata la idea.
7-10 puntos: investiga más. Habla con usuarios, busca workarounds, reduce alcance.
11-14 puntos: construye una prueba de una semana.

La meta no es conseguir una puntuación perfecta. La meta es evitar que una idea con 2 puntos de emoción y 0 puntos de demanda llegue a tu calendario de desarrollo.

Las mejores preguntas para validar sin sesgar

No preguntes:

“¿Te gustaría una app que haga X?”
“¿Pagarías por esto?”
“¿Crees que es buena idea?”
“¿Usarías una herramienta con IA para resolverlo?”

Esas preguntas invitan a respuestas educadas.

Pregunta sobre comportamiento pasado y presente:

“¿Cuándo fue la última vez que te pasó esto?”
“¿Qué hiciste para resolverlo?”
“¿Cuánto tiempo te tomó?”
“¿Qué pasa si no lo resuelves?”
“¿Qué herramientas usas hoy?”
“¿Pagas por alguna solución relacionada?”
“¿Quién más participa en este proceso?”
“¿Qué parte te da más rabia?”
“Si esto desapareciera mañana, ¿qué cambiaría en tu semana?”

El enfoque de The Mom Test va en esa línea: hablar de la vida del usuario, no de tu idea. La validación mejora cuando dejas de pedir aprobación y empiezas a investigar hechos.

Una buena entrevista no termina con “le gustó mi idea”. Termina con frases, ejemplos y comportamientos concretos que te permiten decidir qué hacer.

Ejemplo: aplicar el filtro a una idea de automatización con IA

Idea inicial:

“Un agente de IA para negocios que responden WhatsApp.”

Suena bien, pero es demasiado amplio.

Después del filtro:

Usuario: dueños de academias online pequeñas que venden cursos por WhatsApp y reciben 20-100 consultas semanales.

Problema: pierden ventas porque responden tarde, olvidan hacer seguimiento y no saben qué leads están calientes.

Por qué ahora: están invirtiendo más en contenido y anuncios, pero el volumen de mensajes superó su capacidad manual.

Evidencia: usan etiquetas manuales en WhatsApp, hojas de cálculo, asistentes part-time y audios internos para recordar seguimientos.

Canal inicial: grupos de emprendedores educativos, cuentas de Instagram/YouTube de academias, contactos directos con creadores que venden programas.

MVP de una semana: exportar o capturar leads entrantes, clasificarlos por intención y crear recordatorios de seguimiento en una hoja o CRM simple. Sin chatbot completo.

Esta versión todavía puede morir. Pero ya es una idea que se puede investigar y probar sin construir una plataforma enorme.

Señales de que debes matar la idea

Matar una idea no es fracasar. Es proteger tu foco.

Mátala o déjala en espera si:

No puedes nombrar usuarios reales.
El problema solo aparece cuando tú lo explicas.
Nadie tiene una workaround.
Nadie ha buscado una solución.
El usuario no tiene presupuesto ni autoridad.
No puedes llegar a los primeros usuarios.
El MVP mínimo sigue siendo demasiado grande.
La idea te emociona más por la tecnología que por el dolor.
Todas las respuestas positivas vienen de amigos.

La señal más peligrosa es esta: te cuesta abandonar la idea porque ya imaginaste el producto completo.

Cuando eso pasa, estás validando tu identidad como builder, no una oportunidad de mercado.

Cuándo sí empezar a construir

Empieza a construir cuando tengas una combinación suficiente de estas señales:

Usuario concreto.
Problema claro y costoso.
Urgencia actual.
Personas reales identificadas.
Evidencia de workarounds o gasto.
Canal inicial creíble.
MVP entregable en una semana.
Hipótesis explícita de qué aprenderás con la primera versión.

La primera versión debería tener una pregunta de aprendizaje:

“¿Los usuarios aceptan conectar su WhatsApp o prefieren subir exportaciones?”
“¿El resumen automático realmente ahorra tiempo?”
“¿Pagarían por recibir el reporte listo o solo quieren la plantilla?”
“¿El dolor está en capturar leads o en hacer seguimiento?”

Si no sabes qué pregunta responde tu MVP, probablemente estás construyendo por ansiedad.

Checklist final antes de abrir Claude Code

Copia esto y úsalo cada vez que una idea te tiente.

Idea:

Usuario en una frase:

Problema en una frase:

Por qué ahora:

3-5 personas reales o comunidades donde aparece este usuario:

Evidencia de dolor actual:

Workarounds o soluciones actuales:

Qué están pagando hoy con tiempo/dinero/riesgo:

Dónde encontraré los primeros 10 usuarios:

MVP de 7 días:

Qué NO voy a construir todavía:

Pregunta principal que debe responder el MVP:

Señal para seguir:

Señal para matar la idea:

Si no puedes completar la mayoría de campos, no estás listo para programar. Estás listo para investigar.

Conclusión: la velocidad de construcción exige más disciplina, no menos

La IA redujo el costo de construir. Pero no redujo el costo de elegir mal.

De hecho, lo hizo más peligroso: cuando programar se vuelve fácil, la tentación de construir ideas medio formadas aumenta. Puedes producir prototipos, landing pages y PRDs a una velocidad absurda. Pero si no hay usuario, dolor, canal y demanda, solo estás fabricando evidencia falsa de progreso.

La disciplina moderna del builder no es escribir más código. Es saber cuándo no escribirlo todavía.

Antes de abrir Claude Code, pasa la idea por este filtro:

usuario específico,
problema simple,
urgencia real,
evidencia externa,
canal inicial,
MVP de una semana.

Si pasa, construye pequeño y aprende rápido.

Si no pasa, no lo llames fracaso. Llámalo buen juicio.

Fuentes y material revisado

Discusión original en r/SaaS: “How do you decide an idea is actually worth building before you start coding?”
Comentarios destacados de la comunidad sobre claridad vs demanda, “why now”, usuarios reales, workarounds y canal inicial.
Y Combinator Startup Library: recursos sobre planificación de MVP, hablar con usuarios y encontrar ideas de startup.
Rob Fitzpatrick, The Mom Test: enfoque de entrevistas basado en comportamiento real, no opiniones sobre tu idea.

On This Page