Metodología y aprendizajes

Esta página explica, sin adornos, cómo la fábrica convierte una idea cruda en un MVP que mide demanda real. El recorrido no es lineal ni indulgente: la mayoría de los problemas mueren por el camino, y eso es exactamente lo que debe pasar. Aquí está el proceso completo, las dos líneas de exploración, cómo puntuamos, cómo validamos y qué hemos aprendido al repetirlo decenas de veces.

El proceso, en cinco fases

Fase 1 — Generación masiva

El embudo arranca con cantidad bruta. Lanzamos funnels masivos que producen 553 problemas reales, almacenados en data/problems.json: 205 vienen del funnel B2B, 300 de aplicar la lente de Y Combinator a lo largo de 30 rondas, y 48 de la base histórica. En esta fase no se filtra por calidad ni por gusto; el objetivo es volumen y cobertura de sectores. La selección viene después.

Fase 2 — Estudio YC top-100

De los 553 problemas seleccionamos los 100 de mayor potencial y los sometemos a un estudio en dos olas:

• Wave A — 15 pods de agentes: cada problema pasa por un equipo que responde, una a una, las preguntas que importan. ¿Es un problema real? ¿Aguanta la validación con usuarios simulados? ¿Existe una solución agentic? ¿Hay MVP construible? ¿Se monetiza? ¿Escala? ¿Tiene moat? Cada pod emite un veredicto GO / MAYBE / NO-GO. Sobreviven 32 GO.
• Wave B — 6 paneles de cliente escéptico: a los 32 supervivientes les ponemos delante a un cliente que duda y hace la única pregunta honesta: ¿comprarías esto esta semana? Solo 9 obtienen un GO-FUERTE.

De 100 problemas estudiados a fondo, 9 pasan el corte. Esa tasa de mortalidad es deliberada.

Fase 3 — Harmonización

Tras dos olas con criterios distintos, portfolio y problemas no eran comparables entre sí. Así que re-puntuamos todo bajo una misma lente demand-first. El detalle del scoring está en la sección siguiente. Lo importante de esta fase: corregimos un sesgo que teníamos. Antes, el founder-fit inflaba ideas de nicho hasta el puesto #1 aunque la demanda fuera tibia. Ahora el founder-fit cuenta, pero no manda.

Fase 4 — Programa CEO (autónomo)

Cada problema de alto potencial entra en un pipeline completo antes de tocar una sola línea de landing: validación, TAM/SAM/SOM, cliente específico (ICP), mapa de competidores, modelo de negocio, unit economics y rentabilidad, spec técnica y gate de decisión. Solo los problemas que superan ese pipeline pasan a la siguiente puerta: un MVP smoke-test en un subdominio propio. Ese MVP es una landing que capta waitlist e intención de pago, persistida en D1 — sin Stripe, sin cobro real todavía. La meta operativa son 50 MVPs vivos midiendo señal.

Fase 5 — gstack

Instalamos el toolkit open-source de Garry Tan para operar la fábrica como un equipo, siendo un solo founder. Lo detallamos más abajo.

Las dos líneas

El Programa CEO corre en paralelo por dos carriles, y eso es intencional:

• Track A — mercado: sigue la demanda sin preferencias personales. Aquí el problema gana o pierde por su tracción potencial, no por lo bien que encaje con el founder.
• Track B — founder-fit: explora problemas donde el founder tiene una ventaja real (es el propio usuario, o un insider con conocimiento no replicable).

Mantener los dos carriles separados evita engañarnos: si una idea solo aparece en Track B, sabemos que su atractivo depende de la ventaja del founder, no del mercado.

El scoring

Una sola fórmula, comparable en todo el portfolio:

Score = demanda (0–100) + founder-bonus (+0 a +8)

• La demanda es el eje dominante. Un dolor fuerte con mercado modesto vence a un dolor tibio con TAM gigante.
• El founder-bonus premia ventaja-injusta verificable (founder-as-user o insider con acceso/conocimiento que otros no tienen), no el mero gusto por una idea. Por eso el techo es bajo, +8: puede romper un empate, no fabricar un ganador.

Esta corrección nació de un error real: con el esquema anterior, el founder-fit empujaba ideas de nicho al #1 por encima de problemas con mucha más demanda. La harmonización demand-first lo arregló.

Validación y gates

El modelo de validación tiene capas, y cada una significa algo distinto:

• Validación simulada (Wave A/B): usuarios y clientes escépticos simulados. Es un pre-filtro barato para descartar lo evidente, no es tracción. Pasarla solo significa que la idea merece research, no que alguien vaya a pagar.
• Pipeline completo (Fase 4): validación de mercado, unit economics, competidores y spec. Aquí caen las ideas que parecían buenas hasta hacer los números.
• Gate: puerta explícita. Solo los problemas que la cruzan reciben un subdominio.
• MVP smoke-test: la landing mide waitlist e intención de pago en D1. Es la primera señal de mercado real, no simulada. Gate: ≥10 reservas de pago + ≥8% visitor→waitlist en 30 días.

El principio operativo: pipeline completo antes de lanzar. No construimos MVPs porque sí; construimos solo lo que ya superó la validación de escritorio.

gstack: qué es y cómo lo usamos

gstack es el toolkit open-source (MIT) de Garry Tan, CEO de Y Combinator. Su tesis: una sola persona con las herramientas correctas envía como un equipo de veinte. La barrera de ingeniería ha desaparecido; lo que queda es criterio, gusto y la disciplina de hacer la cosa completa. El "último 10% de completitud" que los equipos solían saltarse ahora cuesta segundos — y por eso se hace siempre.

En la práctica, gstack convierte a Claude Code en un equipo de ingeniería virtual con roles especialistas: un CEO que repiensa el producto, un eng manager que fija la arquitectura, un diseñador que caza el "AI slop", un revisor que encuentra bugs de producción, un QA que abre un navegador real, un oficial de seguridad (OWASP + STRIDE) y un release engineer que envía el PR. Las skills que usamos en la fábrica:

• /office-hours — describir qué estás construyendo y recibir dirección de founder.
• /plan-ceo-review — revisar una idea de feature desde la lente de producto/CEO.
• /qa — testear de verdad en un navegador real (nuestras landings de MVP).
• /cso — auditoría de seguridad antes de manejar datos de usuarios.
• /review — revisión de código antes de mergear.
• /ship — empaquetar y enviar el PR.

gstack enmarca y envía; para construir el MVP con un equipo de ingeniería —el roster de agentes especialistas, el pipeline con compuertas y el método con el que un solo desarrollador ganó el hackathon de Anthropic— ver la pestaña 🤖 Agentes.

Aprendizajes meta

Lo que la repetición nos ha enseñado, destilado:

• Demanda primero. Cuando chocan dolor y tamaño de mercado, gana el dolor. Un pain 3/10 con un TAM de 50B€ no lo compra nadie.
• El patrón que gana combina cuatro cosas: forcing regulatorio con fecha concreta, dolor que se traduce directamente en dinero, un wedge 100% agentic (el agente opera de punta a punta) y un canal de distribución 1→N que no dependa de vender uno a uno.
• Founder-fit moderado. La ventaja del founder cuenta, pero no domina el score. Una idea inejecutable por el operador no vale su puntaje; una idea de nicho no merece el #1 solo por encajar.
• La validación simulada es pre-filtro, no tracción. El cuello de botella real no es saber si la idea gusta — es el tráfico. Sin canal que traiga gente a la landing, no hay señal que medir.
• Pipeline completo antes de lanzar. Nada de MVPs por inercia. Primero validación, números y spec; el subdominio se gana.
• Muere el "copiloto que el humano firma cada caso." Si el operador tiene que revisar y firmar cada output uno a uno, no escala y no es defensible. El wedge ganador es agentic de extremo a extremo, con el humano supervisando, no procesando.

Y un metaaprendizaje sobre el propio proceso: el score de la primera fase es señal ruidosa. El research profundo cambia entre un 15% y un 25% del ranking, casi siempre a la baja, al aparecer aplazamientos regulatorios, competidores recién financiados o incumbentes que integran más rápido de lo previsto. Por eso ninguna idea recibe recursos por puntaje alto sin haber pasado el pipeline completo.