App Idea Factory es el sistema que corre mi pipeline de ideas para que yo no tenga que hacerlo. Tres Claude routines (trabajos calendarizados que le pasan una tarea a un agente Claude y guardan el resultado) cubren scrape, ranking y spec. Cada routine está desacoplada (cada pipeline corre en su propio horario y puede fallar sin tirar a las otras). La superficie de salida es un dashboard en Vercel para navegar, más Slack para el momento en que toco "generar spec" y quiero un brief profundo en mi bolsillo veinte segundos después. La construí porque genero más ideas de producto de las que puedo ejecutar, y las que pierdo suelen ser las que nunca anoté bien. La app de notas se llena. Nada se vuelve a leer. Las buenas se pudren al lado de las malas porque nada las puntea. Quería un sistema que jalara señales de demanda desde donde la gente de verdad se queja del software, las puntara honestamente, y me dejara decidir desde el celular si alguna merece un viernes en la noche. ## El monolito que se rompió tres veces La versión floja de este sistema es un solo agente que escrapea, puntea y escribe un spec en un solo prompt largo. Le tirás Reddit, le tirás Product Hunt, le tirás una rúbrica de scoring, le pedís un reporte en Markdown al final. Funciona para un demo. No sobrevive una semana. Mandé ese monolito. Se rompió de tres formas distintas la primera vez que corrió de verdad. El paso de scrape se quedó sin tiempo antes de que el agente llegara a puntear, y como todo era una sola tarea, perdí el trabajo parcial. Al día siguiente una búsqueda me hizo rate-limit y la corrida entera abortó, sin ideas guardadas, sin auditoría de por qué. Al día siguiente el spec del final estaba decente pero no tenía cómo pedir un spec fresco sobre la idea de ayer sin volver a correr todo el pipeline desde cero. Un agente, un prompt, un solo modo de falla para todo. Así que tiré el monolito y lo partí. La versión partida son tres pipelines que no comparten proceso. Pipeline 1 escrapea. Pipeline 2 puntea. Pipeline 3 escribe specs bajo demanda. Cada uno es su propio routine, con su propio horario, su propio modo de falla y su propia fila en Supabase (un backend Postgres administrado que guarda las ideas, los reportes diarios y los spec jobs). Cuando el scraper choca con un rate limit, el ranker sigue corriendo contra todo lo que ya estaba en la base. Cuando el ranker tiene un mal día, el spec generator sigue trabajando con lo último rankeado. El dashboard lee de la misma base y me muestra el estado actual sin importar cuál pipeline terminó al último. Un pipeline, un trabajo, un modo de falla. La razón por la que puedo dejarlo corriendo desatendido es que cualquier rotura individual queda contenida. ## Cómo corre en realidad Dos disparadores cron hacen el trabajo pesado. Pipeline 1 dispara a las 02:00 hora Guatemala y manda tres subagentes en paralelo: uno para Reddit (r/SaaS, r/AppIdeas, r/dating, r/productivity, varios más), uno para Product Hunt y Hacker News, uno para búsquedas de tendencia tipo "wish there was an app that 2026". Cada subagente regresa con un puñado de pain points y una URL fuente cada uno. El orquestador los deduplica hasta dejar doce a quince ideas únicas, corre una búsqueda rápida de competidor por idea, puntea las cuatro dimensiones e inserta cada fila en Supabase apenas la tiene. Sin batching al final. Si algo falla en la idea doce, las ideas uno a once ya están guardadas. Pipeline 2 dispara a las 04:00, dos horas después, asumiendo que el scraper ya terminó. Carga cada idea jamás guardada, aplica una regla de decay de tendencia (una idea sin menciones en quince días pierde 20% de su score de tendencia, penalizaciones más chicas para gaps más cortos), recalcula el compuesto, fija la bandera del top quince, y elige tres ideas "nuevas esta semana" que cayeron en los últimos siete días. Después le hace ping al endpoint de revalidación del dashboard para que lo que veo en Vercel refleje lo que la base acaba de decidir. Los dos routines nunca se hablan directamente. Comparten la base. Si el scraper se saltó un día, el ranker igual tiene trabajo que hacer sobre la pila existente, lo registra y sigue. Nada espera por nada. ## Qué significa el score en realidad Cuatro dimensiones, ponderadas: tendencia (0.30), competencia (0.25), factibilidad (0.25), novedad (0.20). El agente asigna cada una sobre diez, con una inversión deliberada en competencia donde diez significa "el hueco está bien abierto" y cero significa "saturado, ni te molestés". La factibilidad se calibra contra la pregunta "¿puedo enviar un MVP en dos a cuatro semanas?" no "¿podría un equipo con plata construir esto en un año?". La novedad lleva el peso más bajo a propósito: la novedad es divertida, pero es la dimensión que más fácil engaña, y prefiero construir la app aburrida que otros cinco ya construyeron antes que la idea original que nadie quiere. El decay de tendencia es la parte con la que más discutí conmigo mismo. La regla es simple: una idea que no aparece en ningún lado en tres días pierde tres por ciento de su score de tendencia, en siete días pierde siete por ciento, en quince días o más pierde veinte por ciento. El punto no es descartar ideas viejas. El punto es evitar que un thread aislado de Reddit se quede sentado en el leaderboard un mes sin evidencia fresca. Si la idea es real, vuelve a aparecer. Si no vuelve a aparecer, el score se desvanece calladito. El costo es que una idea callada pero legítimamente buena puede caerse del top quince. La ganancia es que el leaderboard se mantiene honesto. Prefiero perderme un slow burner que entregarle atención a señal muerta. El Claude routine es un componente dentro de este pipeline, no la arquitectura. Hace lo que solo un LLM puede hacer: leer posts sociales desordenados, inferir el dolor de fondo, escribir un spec coherente. Todo lo que lo rodea (el calendario, la deduplicación, las escrituras a la base, la regla de decay, el ping de revalidación, la entrega por Slack) es código plano con contratos explícitos. Cuando algo sale mal, casi siempre sé qué lado se rompió sin abrir la salida del modelo. Esa separación es lo que hace la fábrica barata de correr y fácil de confiar. ## El tap de Slack El spec generator es la parte que más uso, y la parte donde la experiencia de verdad vive. El dashboard en app-factory-ruby.vercel.app es una lista rankeada con un botón "Generate Spec" en cada página de detalle de idea. Apretás el botón, una función serverless en Vercel marca la idea como solicitada, y Pipeline 3 dispara. Pipeline 3 corre bajo demanda, no calendarizado. Carga el registro completo de la idea, escribe un spec en Markdown completo (problem statement, target user, MVP feature set tope cinco, lista de fuera-de-alcance, stack recomendado, preguntas abiertas, desglose de score, fuentes), genera una propuesta de una página en HTML autocontenido, manda el HTML a un endpoint de Vercel que corre Puppeteer para convertirlo a PDF, y entrega el resultado por Slack. La entrega son dos piezas. El routine crea un Slack Canvas con el spec entero acomodado como un documento estructurado, incluyendo una recomendación de "siguiente paso" basada en reglas que elige "build", "validate with five users" o "research further" según el perfil de scores. Después me manda un DM con el título, el score compuesto, el resumen de una línea y un link directo al Canvas. Elegí Slack como superficie de entrega por una razón. El dashboard es para navegar. Slack es para leer en el bus. El Canvas se abre limpio en móvil, queda buscable después, y vive al lado de donde ya recibo notificaciones. El desacoplamiento me compró una propiedad que no esperaba al inicio: la capacidad de volver a correr el spec generator sin volver a correr nada río arriba. Si el spec sale flojo, limpio el spec_status y vuelvo a apretar el botón. Solo Pipeline 3 dispara. El costo de scraping queda preservado, el ranking queda preservado, y solo la etapa más cara, donde más quiero flexibilidad, es repetible. ## Lo que sigo reaprendiendo La movida por defecto con cualquier cosa con forma de LLM es amontonar trabajo sobre el modelo y rezar. Un prompt. Un agente. Una corrida punta a punta. Es la forma más rápida de tener algo que se vea bien en un demo, y la más lenta de tener algo que corra desatendido. La movida opuesta, que es lo que App Idea Factory es, trata al modelo como un componente dentro de un sistema con bordes explícitos. El calendario es cron plano. El almacenamiento es Postgres plano. La matemática de dedup, decay y ranking es determinista. La entrega por Slack es plantilla. El modelo está haciendo la parte que solo un modelo puede hacer: leer lenguaje humano desordenado y producir salida estructurada. Todo lo demás es código que puedo leer en quince minutos y confiar para siempre. Esa es la lección que sigo reaprendiendo entre proyectos. El trabajo interesante con IA no es elegir el modelo. Es el sistema que construís alrededor para que el modelo solo tenga que hacer su trabajo, y para que recibas señal honesta sobre si lo hizo.