Cuando desarrollas por tu cuenta, el cuello de botella no suele ser escribir código.

Es elegir qué merece el siguiente bloque de tiempo.

Hay más ideas que horas.

Algunas parecen obvias porque “todo el mundo las necesita”.

Otras solo existen porque ya sabes cómo implementarlas. Y casi ninguna llega con una señal clara de demanda antes de existir.

Este texto no propone una fórmula.

Resume un conjunto de preguntas que ayudan a descartar antes de invertir semanas.

1. Separa el problema del vehículo

Una idea suele mezclar dos cosas:

El problema que alguien tiene (buscar, filtrar, calcular, recordar, comparar…).

La forma concreta en que crees que se resuelve (una web, un bot, un scraper, un dashboard).

Antes de diseñar pantallas o APIs, escribe solo el problema en una frase.

Si la frase necesita explicar la herramienta para tener sentido, probablemente estás partiendo del vehículo y no del dolor.

2. Busca evidencia que no dependa de ti

Las señales más débiles son las que solo tú generas: “yo lo usaría”, “mis amigos dicen que está bien”, “en

Twitter alguien se quejó una vez”.

Las más útiles suelen ser externas y repetibles:

Gente que ya paga (aunque sea poco) por soluciones imperfectas al mismo problema.

Preguntas recurrentes en foros, comunidades o tickets de soporte de herramientas existentes.

Datos públicos que muestren volumen o frecuencia del problema (sin interpretarlo como garantía de conversión).

Si la única evidencia es tu intuición, anótalo como hipótesis, no como validación.

3. Estima el coste de mantener, no solo el de construir

Una herramienta pequeña puede lanzarse en días.

Mantenerla (datos que cambian, APIs que se rompen, casos límite, soporte, actualizaciones de seguridad) puede ocupar más tiempo del que se invirtió al principio.

Preguntas útiles:

¿Qué parte del sistema depende de fuentes externas que no controlas?
¿Con qué frecuencia habría que revisar o recalcular los datos?
¿Qué pasa si el primer usuario real pide algo que no cabe en el diseño actual?

Si la respuesta a cualquiera de ellas es “no lo sé”, el riesgo no es técnico: es de atención futura.

4. Define un criterio de abandono antes de empezar

Muchas ideas no mueren porque sean malas.

Siguen vivas porque nunca se decidió cuándo dejarlas.

Antes de escribir la primera línea, fija condiciones concretas y observables:

Tiempo máximo que vas a dedicar antes de revisar.

Señal mínima que necesitas ver (registros, uso real, preguntas concretas de posibles usuarios).

Qué harás si esa señal no aparece.

Sin ese criterio, cada idea se convierte en un compromiso indefinido.

5. Prefiere el aprendizaje al lanzamiento perfecto

Un prototipo que permite observar comportamiento real suele enseñar más que una landing pulida sin usuarios.

Eso no significa publicar basura: significa acotar el alcance para que el coste de equivocarse sea bajo.

La pregunta práctica es:

¿qué es lo mínimo que puedo poner delante de alguien para comprobar si el problema existe tal como lo imagino?

Preguntas abiertas

Me interesa cómo lo resolvéis vosotros:

¿Qué señales usáis para decidir que una idea merece tiempo?
¿Habéis abandonado proyectos por el coste de mantenimiento más que por falta de interés inicial?
¿Preferís validar con conversaciones, con datos públicos o con un prototipo mínimo?
¿Cómo evitáis que la facilidad técnica de construir algo se convierta en la razón para construirlo?

No busco la respuesta correcta.

Busco ejemplos concretos de cómo otras personas están tomando (o evitando) esta decisión cuando trabajan solas.