Software factories have been all the rage these last few weeks. So I built one. Here's what I learned, how it works, and how you can build one in an afternoon. My Goals It needed to be really simple, something that just worked and didn't require a bunch of babysitting. Ideally, it would run entirely on my existing Claude subscription. It sounds naive, but essentially unless it integrates easily into my existing workflow, it's not going to be something that sticks around. I don't want to build this and have to change all my existing habits just to use this new system. I know from experience that if that happens, it won't work for me long term and will fade into irrelevance. So instead of attacking this as one big effort, I split it up into two distinct phases: Pre-triage - i.e. figuring out the stuff "to do" Implementation - i.s. actually "doing" the stuff In the center is Linear, the source of truth of what work needs to be done. Every software factory needs to have this centralized repository of work to be done, whether that's GitHub issues, Linear, or something else. It should be what you already use so it's easily extensible for any system to add work for either agents or humans to pick up and complete later. The pipeline has intentionally defined seams that make the process of building a software factory actually manageable: Create work (loops w/ MCPs) Store work (linear) Complete work (SDLC agent) By splitting it up, you don't have to build both the pre-triage and implementation sides at once (and I actually recommend against it to avoid over-engineering). Linear makes the interface between what "to do" and what we're currently "doing" well defined and easy to extend. Pre-Triage Step In the above diagram, the work progresses from left to right. The left side is where work's created and contains any number of systems (either humans, agents, or APIs) that adds to what needs to be done. All outputs created in this pre-triage step is put into our Linear. In this step, we have three main loops: System Health Check Loop (i.e. a bug finder) - this loop runs daily at 5am and is connected to a few MCP servers: Posthog for error tracking; Vercel for system diagnostics; and Linear for creating issues. UX Improvements and Customer Feedback Loop - this loop runs weekly on Monday at 9am, and scans every new piece of feedback, every customer support chat from Intercom/Fin, and all Posthog session replays. Session replays are a goldmine. You can see where rage clicks happen or where users are struggling and confused. Churn Analysis Loop - this runs daily at 6am and investigates every customer that clicked cancel in the last 24 hours. It pulls payment and user data from Stripe (including their email/location), and then looks at this customer's session replay in Posthog to see what they were doing before they cancelled. We pull their usage from Supabase to see if it was a wrong ICP, never experienced that "wow" moment, or hit bugs. The report is sent to Slack and the agent creates (or comments on) issues if they are related to customers churning to bump priority. To actually run these agents consistently, I kept it simple and used Claude Code Cloud Routines. No over-engineering with a Hetzner VPS, a caffeinated mac mini, etc.. It's by far the easiest way I've found to leverage your existing Claude Code subscription and create always on agents that can be triggered on a schedule or via a webhook event. And to all the people saying "but what about vendor lock in!!" - it's literally just some text. Feel free to copy the prompt to wherever you want, I just wanted the easiest and cheapest thing to set up that works reliably. And another reason to use Claude Code Cloud Routines is that Anthropic's cloud environments have close parity with Claude running locally. Obviously they don't have your env vars (which can be added to the cloud environment setup, if needed) but if you set up an MCP connection via the Desktop App's connectors, both your local Claude cli and remote Claude can use them, unlike Codex. This was the killer feature for me and is what makes these pre-triage agent loops work so well. It also makes it easy to run a bunch of sessions in parallel without worrying about your laptop's memory. If you just implement this pre-triage step, you'll still get a lot of leverage even if you don't build the next step where the work is completed. Start small with a single loop, try it out, refine it, then add more. Figure out what routines you can create today that put new, high-quality work into your existing issue tracker and then do whatever you currently do today for implementation. Implementation Step The most basic version of step two is to give your agent an issue ID and say to go complete it. This is what most people already do tday when working with agents, however, it probably isn't what you want if you're reading this, because you're now the bottleneck in the loop, kicking off an agent directly in a session.