Solo Builder Division — should we add an on-ramp for one-person teams?

[msitarzewski]

Issue #196 from @jerrysoer proposed a "Solo Builder" division — 6 agents covering the full lifecycle for solo builders shipping apps fast. The pitch is that existing agents are calibrated for team-scale work, and there's no on-ramp for someone who just wants to ship a working app in a weekend.

The proposed roster:

• Head of Product — scoping, PRD-lite, tech stack
• Head of Design — opinionated UI/UX, picks a design system fast
• Head of Engineering — full-stack, speed-to-deploy
• Head of Security — env vars, auth, OWASP top 10 basics
• Head of Testing — happy path and critical flows only
• Head of Launch — landing page copy, Product Hunt, Show HN, social launch

I genuinely like this idea. The "on-ramp" framing makes a lot of sense — outgrow Head of Engineering, graduate to Senior Developer. It could be the front door for new users.

But it's a new division, which is a big structural decision. Some open questions:

1. Naming — "Solo Builder" feels right, but open to alternatives
2. Agent count — is 6 the right number? Too many? Too few?
3. Depth — should these match full agent depth, or be intentionally lighter?
4. Overlap — how do we draw the line vs. Rapid Prototyper and other existing agents?
5. Audience — is this for true beginners to AI agents, or experienced devs who happen to work solo?

PR #202 from @gbpnkans already has an implementation, which is great energy — but let's get aligned here first so the final version reflects community input.

cc @jerrysoer @gbpnkans — would love both your perspectives here.

[jerrysoer]

Thanks for creating this, @msitarzewski Good to see @gbpnkans already moving on an implementation too — happy to coordinate so we're not duplicating work.

My takes:

1. Naming — "Solo Builder" is the right call. Descriptive, won't age poorly. "Indie" and "Starter" both have baggage.

2. Agent count — 6 maps to the full lifecycle: scope → design → build → secure → test → launch. Fewer and you leave a gap. More and you lose the simplicity that makes it an on-ramp. If forced to cut, I'd merge Head of Product and Head of Design — but I think they're distinct enough to keep.

3. Depth — Intentionally lighter. If the agent files are as dense as the Senior Developer or Security Engineer, new users face the same overwhelm at a different level. Shorter identity sections, fewer rules, more opinionated defaults. The simplicity is the point.

4. Overlap — The line is lifecycle scope. Existing agents go deep on one function. These go wide across the full journey but stay shallow on each step. Rapid Prototyper builds fast but doesn't deploy. Head of Engineering builds and deploys. Security Engineer audits everything. Head of Security checks the 6 things that actually get solo projects hacked. Not replacing depth — giving people a reason to seek it out later.

5. Audience — Both, but lead with the beginner. Experienced devs who work solo will cherry-pick from existing divisions anyway. The person who benefits most just cloned this repo, has never used AI agents, and doesn't know where to start. That said the agents should still be good enough that a senior dev wouldn't feel patronized.

[jnMetaCode]

Love this idea. Solo builders are a huge segment — especially in the Chinese indie dev community where one-person teams ship WeChat mini-programs, cross-border e-commerce tools, and niche SaaS products all the time.

The proposed 6 agents cover the core lifecycle well. A few thoughts:

• Head of Launch could lean more into distribution channels rather than just "launch" — for solo builders, the hard part isn't shipping, it's getting discovered (app stores, Product Hunt, social platforms, SEO).
• Might be worth including a prioritization/scope angle somewhere — solo builders' Welcome to agency-agents Discussions! #1 failure mode is building too much. An agent that helps ruthlessly cut scope would be uniquely valuable.
• The depth question from @jerrysoer is spot on — these should feel different from the existing specialists. More "generalist who can context-switch" and less "deep domain expert."

Happy to help review the PR if useful.

[jerrysoer]

How can we take next steps here?

[Gingiris]

Re: @jerrysoer's question on next steps — happy to offer some thoughts on the Head of Launch agent specifically.

Head of Launch: What It Should Actually Do

From watching ~30+ OSS/indie launches hit #1 on PH and seeing what actually moves the needle for solo builders:

Core Responsibilities

1. Pre-launch checklist generation — README badges, social preview images, one-liner pitch, landing page essentials
2. Channel-specific templates — PH tagline + description, HN "Show" post, Reddit post for r/SideProject, tweet thread
3. Launch timing guidance — PH: Tuesday-Thursday 12:01 AM PT; HN: weekday mornings EST; Reddit: depends on subreddit
4. Day-of coordination — maker comment template, response templates for common questions, when to post where

What Makes It "Solo Builder" Grade

The existing Launch agents in other divisions optimize for team coordination. A Solo Builder version should:

• Be opinionated — "Post this exact text" beats "consider these 5 options"
• Minimize context-switching — one checklist, not scattered guidance
• Assume limited time — prioritize the 3 things that actually matter over comprehensive coverage

Scope Boundary

@jnMetaCode's point about "getting discovered" is right — but I'd split it:

• Head of Launch = the launch event (first 72h visibility spike)
• Distribution/Growth = ongoing channels (SEO, app stores, community building) — arguably a different agent or a "next step" after you've shipped

If there's appetite, I could draft a skeleton for the Head of Launch agent based on patterns from Gingiris's launch playbook — it's CC-licensed and covers the exact checklist structure that works for solo launches.

@gbpnkans — if you're already implementing, happy to review or contribute the launch-specific section.

[gbpnkans]

I will get this going.

[gbpnkans]

Picking up the thread here. The implementation from PR #202 has been rebased onto current `main` and updated based on the feedback in this discussion. Here's where things stand:

What's been incorporated

From @jerrysoer:

• Keeping all 6 agents — the lifecycle coverage (scope → design → build → secure → test → launch) holds up. Fewer and you leave a gap.
• Agents are intentionally lighter than the specialist divisions — shorter identity sections, more opinionated defaults, less deliberation surface area.

From @jnMetaCode:

• Head of Product is built around ruthless scope-cutting as its primary value. "The Kill List" (features explicitly removed + why) is a named deliverable.
• Agents are framed as generalists who context-switch, not deep specialists with domain breadth.

From @Gingiris:

• Head of Launch has been tightened to the first 72h launch event, not ongoing distribution.
• Added specific structure: pre-launch checklist (og:image, one-liner, landing page), channel copy kit (PH tagline/description/Maker comment, Show HN, Reddit r/SideProject, Twitter thread), timing guidance (PH: Tue–Thu 12:01 AM PT, HN: weekday mornings EST), and a day-of playbook.
• Agent delivers ready-to-paste copy — no options menu, just the text.

Current state

All 6 agents complete:

Agent	Scope boundary
Head of Product	Scope-cutting, PRD-lite, stack decisions
Head of Design	Design system selection, component choices
Head of Engineering	Full-stack build through deployment
Head of Security	The 6 things that actually get solo projects hacked — not SOC2 theater
Head of Testing	Happy path + critical flows only
Head of Launch	First 72h visibility window — stops before ongoing distribution/growth

Ready to open a new PR against `msitarzewski/agency-agents` main. Want me to go ahead, @msitarzewski?

[Gingiris]

Thanks for picking this up and sharing the updated implementation! The rebased version looks solid — really appreciate the thorough incorporation of feedback from @jerrysoer and others.

The lifecycle coverage (scope → design → build → secure → test → launch) makes a lot of sense for solo builders who need a clear mental model. Happy to see this moving forward as a PR.

For anyone exploring growth and visibility strategies for open-source agent projects, you might also find the Gingiris OSS Launch Marketing Playbook useful — it covers GitHub star growth, community seeding, and Hacker News launch tactics specifically for solo builders and small teams.