A Review Board for a Company of One

The trap of building a product with a team of one or two: A lot of people think it's the workload, it's not. (Though this is a different challenge.)

The worst part is, that nothing really gets challenged.

At my last company a spec never reached a client without someone finding something is missing in it. An engineer might ask what happens when the API times out. An exec asking why we are focusing on this feature now and not the other things in the Backlog. Somebody in the room always wanted something I hadn't accounted for, and the document got better because of it. Building with a small team (or if you're in a solo project), that part of crucial feedback is just gone.

Building NearBuy with a small team, or building small little other projects, that feedback is just very limited. My first draft is my (almost) final draft.

Because this feedback is so important when building prodcuts, I built myself a review board of experts, simply out of markdown files with context and behaviour. Eight Claude Code subagents, each one a specific kind of critic, each one able to tear into a spec, a deck, or a post before a real person has the chance. They live in a folder. You can download them here and drop them into your own project.

This is what I've learned running them.

What a subagent actually is

Worth being precise, because "agent" has been stretched until it means nothing.

In Claude Code, a subagent is a specialised assistant defined by a markdown file. The relevant mechanics: each subagent runs in its own context window with a custom system prompt, specific tool access, and independent permissions. When Claude hits a task matching a subagent's description, it delegates, and the subagent works independently and returns its result.

The reason this exists is context. A side task that would otherwise flood your main conversation with search results, logs, and file contents you'll never look at again instead happens inside the subagent's own window, and only the summary comes back. Your main thread stays clean.

That's the engineering rationale. For my purposes there's a second benefit that matters more: isolation produces genuine independence. An agent reviewing my PRD hasn't sat through the two hours in which I talked myself into it. It sees the document, not my reasoning about the document. That's exactly what a reviewer should be.

Installation is unglamorous: drop the .md files in .claude/agents/ in your project (or ~/.claude/agents/ to have them everywhere), and Claude Code picks them up. /agents lists and manages them.

The eight

Grouped by what they're actually for, not alphabetically.

The adversaries — agents with a position that conflicts with mine:

• skeptical-customer — my ICP, who has heard every pitch in the category and is unimpressed
• investor — a seed investor going at the deck and the metrics
• engineer — feasibility, architecture, and the true cost of the thing I've casually specced

The specialists — agents with a body of craft knowledge:

• financial-advisor — pricing, unit economics, runway, model sanity
• brand-expert — identity and consistency across touchpoints
• social-media-expert — posts, captions and calendars, judged against stage and audience

The synthesiser — the one that isn't a critic at all:

• user-researcher — turns raw interview notes and field observations into themes

The framer:

• executive — strategic framing, stakeholder alignment, the version that survives contact with a leadership team

What separates the ones that work from the ones that don't

After a first test run I was amazed.

The agents that earn their keep are the ones with a stake that opposes mine. skeptical-customer and investor produce feedback I could not have generated by trying harder, because their objections come from a position I don't hold. The skeptical customer doesn't care that the architecture is elegant. The investor doesn't care that the feature is delightful. Getting hit from an angle you don't naturally occupy is the entire point of a review board.

The agents that risk being theatre are the ones that share my perspective. executive is the honest example. I'm a product person who's spent a decade doing strategic framing — a fair amount of what it returns is what I'd have written on a good day. It becomes genuinely useful in one specific mode: when I hand it something already written and ask it to argue the opposite strategic call. Prompted for critique it partly echoes me. Prompted for opposition it earns its slot.

The general rule I'd extract: an agent is worth having when it holds information or incentives you don't. Otherwise you've built a mirror and called it a panel.

Four things I got wrong first

1. Assuming the agent could see my conversation. It cannot, and this is the single most common failure. A subagent's context window starts fresh — the only channel from the parent is the prompt string, so any file paths, decisions, or context it needs has to go in there explicitly. My first investor review was confidently generic because I'd asked it to "review the deck" without telling it which deck. Name the files. Every time.

2. Letting reviewers write. A reviewer with edit access will helpfully improve your document, which is the opposite of what you asked for. Restrict the tools in the agent definition to reading — the standard advice is to keep an agent read-only unless it genuinely needs to change files, and for critics that's permanent. I want the critique in a form I have to think about, not silently applied.

3. Running the whole panel on everything. Eight reviewers on a one-page spec produces eight pages of feedback and a worse document, because I end up flattening every objection into mush trying to satisfy all of them. Match the panel to the artifact: a pricing page gets financial-advisor + skeptical-customer. A PRD gets engineer + user-researcher + executive. A launch post gets social-media-expert + brand-expert. Two or three, chosen deliberately.

4. Treating agreement as validation. When all of them passed something early on, I took it as a green light. It wasn't — it meant my agent prompts were too agreeable. A reviewer that never fails anything isn't a reviewer. If you've read anything about LLM evals, this is the same problem in a different costume: an evaluator has to be validated against reality before you're allowed to trust it. I now periodically check a critique against what a real person said about the same artifact.

The consolidation step is the actual work

Here's the part that isn't automatable, and shouldn't be.

Three agents will give you three sets of objections that partly contradict each other. The engineer wants scope cut; the investor wants ambition raised. Deciding which critiques to act on, which to note and defer, and which to reject outright — that's product judgment, and it's the entire job. The panel doesn't make the decision. It makes sure the decision is informed, which is a different and more useful thing.

But there is an honest trade-off: it will not make you faster. But it will surely improve your ouput. Doing things fast and breaking them, is not the way anymore when you are going a thousand miles an hour. That's the trade, and for anything that a customer, investor or engineer will actually read, it's obviously worth it.

Where this goes next: loops

Everything above is on-demand. I have a document, I invoke a panel, I read the critique. The agent is a tool I pick up.

The next step is the thing serious builders have moved to. Boris Cherny, who created Claude Code, has said he no longer writes prompts — he writes loops that run. Peter Steinberger of OpenClaw makes the same point: stop prompting your agents and start designing the loops that prompt them.

Aakash Gupta's guide to loops for PMs draws the distinction I found most clarifying. A loop isn't a scheduled task and it isn't a goal definition — the schedule is merely the trigger, and the goal is merely the criteria. A loop is the whole self-starting system: it fires, does the work, and hands you an output without you initiating anything. His examples map exactly onto the PM work that repeats — weekly business review, sprint prep, monthly synthesis of interview themes. (The deeper mechanics of his framework are behind a paywall, and I'd say the first section alone is worth reading before you decide.)

Put the two together and the shape is obvious. Agents are the who. Loops are the when. A review agent invoked by hand catches problems in the documents I remember to check. The same agent inside a loop catches them everywhere, on a schedule, whether I remember or not.

Concretely, the two I'm building for NearBuy:

• Content quality gate. My publishing pipeline already generates drafts on a Thursday and surfaces them in Notion for weekend review. Adding social-media-expert and brand-expert as a step before that queue means nothing reaches my review board without having already failed once and been fixed.
• Weekly metrics interrogation. A loop that pulls NearBuy's numbers every Monday and runs investor against them — with the standing question: what would a seed investor ask about this week, that I would rather not answer?

The second one is the one I actually want. Not because the analysis will be brilliant, but because a question I'm avoiding is much harder to keep avoiding when it arrives in my inbox on a schedule.

Which is, when I'm honest, what the whole review board is for. Not to replace the room full of people who used to find the holes in my thinking. Just to make sure something still does.

---

The eight agents are free to download and use. If you improve one, I'd like to know — tell me what you changed.