App Idea Factory is the system that runs my idea pipeline so I don't have to. Three Claude routines (scheduled jobs that hand a task to a Claude agent and capture the result) cover scrape, rank, and spec. Each routine is decoupled (each pipeline runs on its own schedule and can fail without taking the others down). The output surface is a Vercel dashboard for browsing, plus Slack for the moment I tap "generate spec" and want a deep brief in my pocket twenty seconds later. I built it because I generate more product ideas than I can act on, and the ones I lose are usually the ones I never wrote down properly. Notes app fills up. None of it gets re-read. The good ones rot next to the bad ones because nothing ranks them. I wanted a system that would pull demand signals from where people actually complain about software, score them honestly, and let me decide on my phone whether any of them deserve a Friday night. ## The monolith that broke three ways The lazy version of this system is a single agent that scrapes, ranks, and writes a spec in one long prompt. Hand it Reddit, hand it Product Hunt, hand it a scoring rubric, ask for a Markdown report at the end. It works for a demo. It does not survive a week. I shipped that monolith. It broke in three different ways the first time it ran for real. The scrape step timed out before the agent ever got to scoring, and because everything was one task, I lost the partial work. The next day a search rate-limited me and the entire run aborted, no ideas captured, no audit of why. The day after that the spec at the end was decent but I had no way to ask for a fresh spec on yesterday's idea without re-running the whole pipeline from scratch. One agent, one prompt, one failure mode for everything. So I scrapped the monolith and split it. The split version is three pipelines that don't share a process. Pipeline 1 scrapes. Pipeline 2 ranks. Pipeline 3 writes specs on demand. Each one is its own routine, with its own schedule, its own failure mode, and its own row in Supabase (a managed Postgres backend that stores the ideas, the daily reports, and the spec jobs). When the scraper hits a rate limit, the ranker still runs against everything that was already in the database. When the ranker has a bad day, the spec generator still works on whatever was last ranked. The dashboard reads from the same database and shows me the current state regardless of which pipeline last finished. One pipeline, one job, one failure mode. The reason I can leave it running unattended is that any single break is contained. ## How it actually runs Two cron triggers do the heavy lifting. Pipeline 1 fires at 02:00 Guatemala time and dispatches three subagents in parallel: one for Reddit (r/SaaS, r/AppIdeas, r/dating, r/productivity, several others), one for Product Hunt and Hacker News, one for trend searches like "wish there was an app that 2026". Each subagent comes back with a handful of pain points and one source URL each. The orchestrator dedupes them down to twelve to fifteen unique ideas, runs one quick competitor lookup per idea, scores the four dimensions, and inserts each row into Supabase as soon as it has it. No batching at the end. If something fails on idea twelve, ideas one through eleven are already saved. Pipeline 2 fires at 04:00, two hours later, on the assumption that the scraper has finished by then. It loads every idea ever stored, applies a trend-decay rule (an idea that hasn't been mentioned anywhere for fifteen days loses 20% of its trend score, smaller penalties for shorter gaps), recomputes the composite, sets the top fifteen flag, and picks three "new this week" ideas that landed in the last seven days. Then it pings the dashboard's revalidation endpoint so what I see on Vercel reflects what the database just decided. The two routines never talk to each other directly. They share the database. If the scraper skipped a day, the ranker still has work to do on the existing pile, and it logs and moves on. Nothing waits on anything else. ## What the score actually means Four dimensions, weighted: trend (0.30), competition (0.25), feasibility (0.25), novelty (0.20). The agent assigns each one out of ten, with a deliberate inversion on competition where ten means "the gap is wide open" and zero means "saturated, do not bother". Feasibility is calibrated against the question "can I ship an MVP in two to four weeks?" not "could a funded team build this in a year". Novelty is the lowest weight on purpose: novelty is fun, but it is the dimension most likely to mislead, and I would rather build the boring app five other people built than the original idea no one wants. Trend decay is the part I argued with myself the longest about. The decay rule is simple: an idea that hasn't shown up anywhere in three days loses three percent of its trend score, in seven days loses seven percent, in fifteen-plus days loses twenty percent. The point isn't to discard old ideas. The point is to stop a one-shot Reddit thread from sitting on the leaderboard for a month with no fresh evidence. If the idea is real, it surfaces again. If it doesn't surface again, the score quietly fades. The cost is that a quiet but legitimately good idea can drift off the top fifteen. The gain is that the leaderboard stays honest. I would rather miss a slow burner than hand attention to dead signal. The Claude routine is one component in this pipeline, not the architecture. It does what only an LLM can do: read messy social posts, infer the underlying pain, write a coherent spec. Everything around it (the schedule, the deduplication, the database writes, the decay rule, the revalidation ping, the Slack delivery) is plain code with explicit contracts. When something goes wrong, I almost always know which side broke without opening the model output. That separation is what makes the factory cheap to run and easy to trust. ## The Slack tap The spec generator is the part I use most, and the part where the experience actually lives. The dashboard at app-factory-ruby.vercel.app is a ranked list with a "Generate Spec" button on every idea detail page. Press the button, a serverless function on Vercel marks the idea as requested, and Pipeline 3 fires. Pipeline 3 is on-demand, not scheduled. It loads the full idea record, writes a complete Markdown spec (problem statement, target user, MVP feature set capped at five, out-of-scope list, recommended stack, open questions, score breakdown, sources), generates a one-page proposal in self-contained HTML, sends the HTML to a Vercel endpoint that runs Puppeteer to convert it to PDF, and then delivers the result through Slack. Delivery is two pieces. The routine creates a Slack Canvas with the full spec laid out as a structured document, including a rule-based "next step" recommendation that picks "build", "validate with five users", or "research further" based on the score profile. Then it sends me a DM with the title, the composite score, the one-line summary, and a link straight to the Canvas. I picked Slack as the delivery surface for one reason. The dashboard is for browsing. Slack is for reading on the bus. The Canvas opens cleanly on mobile, is searchable later, and lives next to where I already get notifications. The decoupling bought a property I did not expect at the start: the ability to re-run the spec generator without re-running anything upstream. If the spec comes back weak, I clear the spec_status and tap the button again. Only Pipeline 3 fires. The scraping cost is preserved, the ranking is preserved, and only the most expensive stage, where I most want flexibility, is replayable. ## What I keep relearning The default move with anything LLM-shaped is to pile work onto the model and hope. One prompt. One agent. One end-to-end run. It is the fastest way to get something that demos, and the slowest way to get something that runs unattended. The opposite move, which is what App Idea Factory is, treats the model as one component inside a system with explicit boundaries. The schedule is plain cron. The storage is plain Postgres. The dedup, decay, and ranking math are deterministic. The Slack delivery is templated. The model is doing the part only a model can do: reading messy human language and producing structured output. Everything else is code I can read in fifteen minutes and trust forever. That is the lesson I keep relearning across projects. The interesting AI work is not the model picking. It is the system you build around it so the model only has to do its job, and you get an honest signal back about whether it did.