How Solo Indie Hackers Ship Faster With the Dark Factory Method
For Solo indie hackers and startup founders · Based on Koc Dark Factory Agent Orchestration Method
// TL;DR
Solo indie hackers face the ultimate brain-space constraint: one person, one brain, all the decisions. The Dark Factory method lets you run 3-5 parallel AI agent swim lanes — unsupervised CI fixes running in the background while you actively guide feature development in another lane. Use it when you want team-scale shipping velocity without a team. The key is ruthless scoping: use the plugin architecture to keep your core small, nuke waffling sessions instantly to protect your limited cognitive budget, and let the test harness gate merges instead of manual review.
Why should a solo indie hacker care about factory management?
As a solo builder, your instinct is to write code yourself or to paste tasks into an AI agent and hope for the best. The first approach doesn't scale; the second is Ralph looping — burning tokens for hours with no structured outcome. The Dark Factory method gives you a middle path: structured orchestration of multiple agent sessions so you can ship features, fix bugs, and maintain CI simultaneously.
The factory manager mindset is especially powerful for solo developers because it forces you to confront the real bottleneck: not coding speed, but taste. Your competitive advantage as a solo founder is your product vision and architectural judgement. The agents handle the physical coding; you manage the production line.
How do you run swim lanes when you're one person?
Brain-space is your hardest constraint. Start with a maximum of 3-5 swim lanes:
- Lane 1: CI and test health. Set it to 'take your time, commit when green.' This lane runs unsupervised while you focus elsewhere.
- Lane 2-3: Active feature development. You are in conversation with the agent, reviewing its reasoning, and checking in before commits. This is where your brain-space goes.
- Lane 4: Horizon scanning. Point it at your error logs, support tickets, or analytics to surface issues before users complain.
Clone your repo separately for each lane. Do not use Git work trees — if one lane's heavy test run crashes work trees, it takes down all your lanes simultaneously. Isolation is cheap insurance.
How do you avoid burnout and fire dumps as a solo dev?
The 'no' mechanism is even more critical for solo developers than for teams. You cannot afford to maintain sprawling feature additions. For every feature you're tempted to add, ask: does this belong in core? If it's a nice-to-have or an integration, build it as a plugin. Keep your core surface area as small as your team — which is one person.
Also, be ruthless about the waffling signal. When an agent session starts producing circular explanations, nuke it immediately. As a solo dev, every minute spent nursing a derailed session is a minute stolen from a lane that could be producing real commits. Your cognitive budget is finite and non-renewable within a work session.
How do you use dot-skills to maintain momentum across sessions?
Solo developers often work in bursts — a few hours in the morning, a sprint on weekends. Dot-skills files are your continuity mechanism. After each session, feed the agent's logs through your skill-improvement loop: note where the agent drifted, what corrections you made, and what context it needed. Update the dot-skills file. Next session, load it as persistent context. Over time, your dot-skills compound — each session starts smarter than the last.
What should you do next?
Pick your highest-priority feature and your most annoying CI issue. Clone your repo twice. Open Lane 1 for the CI fix with a low-babysitting mandate. Open Lane 2 for the feature with active conversation. Run them simultaneously for two hours. After the session, write your first dot-skills file capturing what you learned. That's your factory's first shift.
// FREQUENTLY ASKED QUESTIONS
Is the Dark Factory method overkill for a solo developer?
No — it's scaled to your constraints. The method works with as few as 3 swim lanes. A solo developer running 2-3 parallel agent sessions with structured mandates ships faster than one trying to do everything sequentially. The swim-lane discipline prevents the scattered, context-switching workflow that burns out solo devs. Start small, scale lanes as your factory management intuition develops.
How do I manage the test harness if I don't have good test coverage yet?
Build the harness first, before opening feature swim lanes. Dedicate your first sprint entirely to having an agent generate comprehensive tests for your existing codebase. These tests will over-fit to current behaviour, and that's fine — they become your safety net. Once the harness exists, you can trust it as your merge gate and stop manually reviewing every diff, which is the unlock for parallel lane velocity.
What if I can't afford the compute to run multiple agent sessions?
Token cost is rarely the real constraint — brain-space is. But if compute is limited, run fewer lanes and make them count. One unsupervised CI lane plus one active feature lane is the minimum viable factory. Use dot-skills files to maximize the value of each session. As your project generates revenue, scale compute. The method's value comes from structured orchestration, not from raw lane count.