How Can Solo SaaS Developers Use the Dark Factory Method?
For Solo SaaS developers · Based on Koc Dark Factory Agent Shipping Method
// TL;DR
Solo SaaS developers are the most resource-constrained builders in software. The Dark Factory method lets you multiply your output by running 3–5 parallel agent swim lanes: one for active feature development, one for autonomous test writing, and one for documentation with a loaded .skills file. Only one lane requires active conversation at a time, keeping brain-space manageable. The test harness gates your merges, .skills files eliminate re-prompting overhead, and waffling detection prevents you from burning tokens on stuck agents.
Why should a solo developer adopt the factory-manager mindset?
As a solo SaaS developer, your biggest constraint isn't money or tokens — it's your time and attention. The Dark Factory method reframes your role from craftsman writing every line of code to factory manager orchestrating autonomous agents. This is how small teams and solo builders ship at velocities that were previously impossible.
Vincent Koc's framework was built for exactly this scenario: a small team with day jobs needing to ship a major project while handling incoming work. The swim-lane structure ensures you never lose coherence even when multiple work streams run simultaneously.
How do you set up swim lanes as a solo developer?
Start with three swim lanes, each pointing at a separate repo clone:
1. Feature Development (active conversation): This is your primary focus lane. The agent investigates, reports back, and you direct next steps. This lane gets your full attention.
2. Test Writing (autonomous): Give this agent a standing instruction — 'write tests for module X, commit when green.' Minimal babysitting required.
3. Documentation (semi-autonomous): Load a technical writing .skills file so the agent uses consistent structure without re-prompting. Review at merge time.
Clone your repo three times. Don't use Git worktrees — they cause resource contention. Point each agent session (Codex, Claude, or similar) at its own clone.
How do you manage brain-space with multiple active agents?
The key constraint for solo developers is that only one lane should require active dialogue at any time. Feature development is your conversational lane. Tests and docs run autonomously in the background. Check on them periodically — read the agent's self-explanations like status updates from a team member.
If a background lane's output sounds off — circular reasoning, vague assertions, over-confidence about the wrong thing — nuke the session. Don't try to rescue it. Reassign the task to a fresh session. This waffling detection skill develops through practice and is one of the highest-leverage abilities in the Dark Factory method.
How do .skills files save you time as a solo builder?
Without .skills files, you re-explain context to every new agent session. With them, you load a versioned instruction file that encodes your opinionated defaults: documentation structure, test patterns, commit conventions, coding style. This eliminates the re-prompting tax and compounds in value over time.
After each heavy session, review your agent logs. Where did instructions produce poor output? Update the .skills file. Redeploy. This retrospective loop is what separates builders who get faster over time from those who plateau.
What does the test harness do for a solo developer?
The test harness replaces the code review you can't do yourself at speed. When you're merging changes from three simultaneous swim lanes, you can't read every diff. The principle 'In Harness We Trust' means the test suite — even over-fitted tests — is your ground truth. If tests go green after a change, you're at least directionally correct. Never delete tests during a large change, even if they seem overly specific.
What's the next step?
Clone your repo three times today. Start one feature session with active conversation, one test session with standing commit instructions, and one docs session with a .skills file. Run the test harness before every merge. After your first session, update your .skills files with what you learned. You'll ship more in one afternoon than you used to ship in a week.
// FREQUENTLY ASKED QUESTIONS
How many agent sessions should a solo developer run at once?
Start with 3 swim lanes: features (active), tests (autonomous), and documentation (semi-autonomous). Only one lane should require active dialogue at a time. Scale to 5 lanes as you build waffling-detection intuition. The constraint is your brain-space — not compute. More lanes without monitoring discipline produces chaos, not velocity.
Can a solo developer afford the token cost of running multiple agents?
The Dark Factory method prioritizes token efficiency over token maxing. You spend fewer tokens per session by loading .skills files (eliminating re-prompting), nuking waffling sessions early (avoiding wasted loops), and setting autonomy levels (not over-monitoring low-risk work). Most solo developers find the productivity gain far outweighs the marginal token cost.
What if I don't have any tests in my SaaS project yet?
Make test writing your first autonomous swim lane. Even over-fitted tests generated by agents are valuable guardrails for future changes. Assign an agent with standing instructions to write tests and commit when green. This builds your harness incrementally. Without any test harness, you lose the primary quality gate that makes extreme velocity safe.