ideastack·8 min read·
Claude Code subagents for UK indie hackers: the parallel-build unlock
Most UK indie hackers using Claude Code never touch subagents. They are the single biggest unlock in the tool, and they are buried two levels deep in the docs. The result: weekends that should ship five things ship three. This post fixes that - the 30-second definition, three concrete weekend scenarios where subagents save 60-90 minutes each, copy-paste prompts for each, and the honest 'when not to use them' because they are a power tool, not magic.
Most UK indie hackers using Claude Code never touch subagents. They are the single biggest unlock in the tool, and they are buried two levels deep in the documentation. The result: weekends that should ship five things ship three, because three of them ran sequentially when they could have run in parallel.
This post fixes that. The 30-second definition. Three concrete weekend scenarios where subagents save 60-90 minutes each. Copy-paste prompt patterns for each. And the honest "when not to use them" — because they are a power tool, not magic.
What a subagent actually is (30 seconds)
A subagent is a separate Claude Code instance that the main agent dispatches to do a self-contained job. It has its own context window (so it doesn't pollute the main thread), its own tools, and returns a final summary back to the main agent when it finishes.
Two things matter here:
- Context isolation. The subagent burns its own tokens reading 30 files; the main agent gets a 200-word summary. You preserve your main context for the decision-making work.
- Parallelism. Dispatch three subagents in one prompt and they run concurrently. A 90-minute sequential job becomes a 30-minute parallel one.
That's it. The pattern is "dispatch a smaller version of myself, isolate its context, get a summary back."
When subagents pay off (the three weekend scenarios)
Scenario 1: parallel research at the start of a build
You're spinning up a new weekend project. You know roughly what you want, but you need three lookups before you can write the first line of code:
- What's the current Stripe UK pricing model and Customer Portal config?
- What's the Resend free-tier quota and rate limit?
- What's the Supabase EU-West region status (any incidents in the last 30 days)?
Done sequentially, that's 15 minutes per lookup including the agent reading docs, comparing pages, summarising. About 45 minutes total. Done in parallel via subagents: about 15 minutes elapsed.
Prompt pattern:
Dispatch three subagents in parallel, all read-only:
1. Subagent "stripe": research current Stripe UK pricing for
recurring GBP 5/month subscriptions. Return: per-transaction
fees, dispute rates, Customer Portal config options.
2. Subagent "resend": research current Resend free-tier quota,
rate limit, and what triggers a Pro upgrade. Return: hard
numbers + the URL where you found each.
3. Subagent "supabase": check Supabase status page for EU-West
incidents in the last 30 days. Return: any incidents >5 min,
plus current SLA.
Wait for all three. Synthesise into one paragraph each.
You'll get three structured summaries back, the main agent has spent maybe 10% of its token budget, and you can start building immediately.
Scenario 2: parallel scaffolding of independent modules
You've decided your weekend project needs four pieces: a landing page, a Stripe webhook handler, a Supabase users table + RLS policies, and a Resend email job. None of them depend on each other yet (you'll wire them in step five). Sequential scaffolding takes about 80 minutes. Parallel scaffolding takes about 25 minutes elapsed.
Prompt pattern:
Dispatch four subagents in parallel. Each one scaffolds one
piece. No piece depends on another at this stage.
1. Subagent "landing": create app/page.tsx with hero, three-point
value prop, FAQ, subscribe button. Tailwind 4. No data fetching.
2. Subagent "stripe-webhook": create app/api/stripe/webhook/route.ts
that handles checkout.session.completed and updates
users.stripe_customer_id. Use stripe-node v15+.
3. Subagent "supabase-schema": create supabase/migrations/0001-users.sql
with users (id, email, stripe_customer_id, created_at) + RLS
policies (user can read/update own row only).
4. Subagent "resend-job": create app/api/cron/weekly-email/route.ts
that calls Resend with subject "Your week on the rails" for
every user where stripe_customer_id IS NOT NULL.
Wait for all four. Final commit on the main thread.
The main agent reviews the four outputs, runs the build, fixes the inevitable two small integration bugs, commits. Saturday morning, done.
Scenario 3: parallel test-writing for an existing module
You've shipped v1 on Sunday night. Monday evening you want to backfill tests for the parts you ducked over the weekend. Three test files — one for the Stripe webhook, one for the email job, one for the Supabase user creation flow. Sequential: 60 minutes. Parallel: 20 minutes.
Prompt pattern:
Dispatch three subagents in parallel, each writes one test file
using vitest + @testing-library:
1. Subagent "test-webhook": read app/api/stripe/webhook/route.ts
and write app/api/stripe/webhook/route.test.ts. Cover: valid
webhook updates user, invalid signature is rejected, unknown
event type is logged but doesn't 500.
2. Subagent "test-email": read app/api/cron/weekly-email/route.ts
and write app/api/cron/weekly-email/route.test.ts. Cover:
only users with stripe_customer_id receive email, Resend
errors are retried once, no email is sent twice for the same
week.
3. Subagent "test-users": write supabase/tests/users.test.ts.
Cover: RLS lets a user read their own row, RLS blocks a user
reading another user's row, the trigger fires on insert.
Wait for all three. Run pnpm test to confirm green.
The main thread spends its time reviewing the three test files, not writing them.
The honest "when not to use them"
Subagents are not free. Three things to know.
They cost tokens
Each subagent spins up its own context, reads its own files, burns its own tokens. For trivial jobs ("fix this typo"), the overhead is more than the work. Rule of thumb: a job worth dispatching to a subagent should be at least 5 minutes of sequential work. Anything shorter, do inline.
They can't share context easily
If the four scaffolding pieces actually depend on each other (the email job imports a helper that the webhook also imports), parallel dispatch will produce three slightly different versions of the helper. The fix is to scaffold the shared helper first, on the main thread, then dispatch parallel jobs that import it.
They can't ask you questions mid-flight
A subagent runs to completion before it returns. If it hits ambiguity (which Stripe price ID? which database column?), it makes a guess. The main agent then has to detect the wrong guess and re-dispatch with a correction. For high-stakes decisions, keep the work on the main thread where the agent can stop and ask.
The CLAUDE.md / agent-roster pattern
If you find yourself dispatching the same three or four subagents on every weekend project, formalise them. Add an "Agent roster" section to CLAUDE.md:
## Agent roster
| Agent | Role | Prompt prefix |
|---|---|---|
| Researcher | Read-only web research, returns structured summary | "Dispatch researcher subagent..." |
| Scaffolder | Creates new files following the stack rules in CLAUDE.md | "Dispatch scaffolder subagent..." |
| Test-writer | Writes vitest tests for existing source files | "Dispatch test-writer subagent..." |
That's the same pattern Pablo (the AI PM this whole project runs on top of) uses to route work to its subagents. It compounds: by month three you have a short list of trusted agent shapes and the main thread spends its time deciding what to dispatch, not how to dispatch it. See yesterday's CLAUDE.md primer for where this section goes.
A weekend with subagents vs without
The numbers, calibrated against a typical UK weekend build (Next.js + Supabase + Stripe + Resend, GBP 5/month micro SaaS):
| Stage | No subagents | With subagents | Saved |
|---|---|---|---|
| Friday research | 45 min | 15 min | 30 min |
| Saturday scaffold | 80 min | 25 min | 55 min |
| Sunday tests | 60 min | 20 min | 40 min |
| Total weekend | ~3h 5min | ~1h 0min | ~2h 5min |
Two hours back in a weekend that is already squeezed for time. That's the unlock. Use it on the Friday research and Saturday scaffold; you get to spend the saved time on the things that don't parallelise — the friend feedback loop, the polish, and the celebratory pint when the first GBP 5 customer pays you.
Want a data-backed UK business idea every week? Free reports drop every Thursday — keyword volumes, SERP analysis, builder prompts. Browse the latest free report on IdeaStack.
Frequently asked
### How do I actually dispatch a subagent in Claude Code?
You don't need a special syntax. In the main session, write a prompt that explicitly asks for subagent dispatch — for example, "Dispatch three subagents in parallel, the first reads X, the second reads Y, the third reads Z, then return summaries." Claude Code will recognise the pattern and use its Task tool to spin them up. The agent will also do this on its own when it detects parallel independent work, especially if your CLAUDE.md mentions an agent roster.
Do subagents work in Cursor or OpenCode?
Not in the same shape. Cursor is single-thread by design; its composer agent doesn't dispatch parallel sub-instances. OpenCode supports parallel tool calls but doesn't have the same "isolated subagent context" pattern. Subagents are a Claude-Code-native unlock and one of the genuine reasons to be on Claude Code if you do lots of weekend parallel work.
What's the token cost of dispatching three subagents at once?
In rough numbers: each subagent burns 5-15k input tokens for context plus its working output. Three parallel subagents on a research task might cost you 30-50k tokens total. On Anthropic Pro at GBP 17/month with its quota, that's well within budget for a weekend project. On Max (GBP 80/month) you can run them all day.
Can subagents call subagents?
Yes, technically. In practice it's a bad idea. The deeper the nesting, the harder it is to debug when one of them does the wrong thing, and the more expensive the run becomes. Stick to one level — main agent dispatches subagents, subagents do the work, summaries come back to main.
What's the biggest beginner mistake with subagents?
Dispatching them for jobs that aren't actually parallel. If subagent B needs to read what subagent A wrote, that's not parallelism — that's a pipeline, and it should be sequential calls from the main thread, not concurrent subagents. The test: if any of your dispatched jobs need the output of another dispatched job, you're not parallel.
Filed under
