One Person Managing 5 Products, 80% Time Not Writing Code — Thanks to This One Step

Every single-person team runs 5 products. The core is one extra step after each feature: save the solution into the system so AI avoids the same pitfalls next time.

⚑ Position note: This article is Every’s own account of its “Compound Engineering” methodology and its open-source plugin practice. The concurrency scale, time allocation, and product count are all official figures. Below is just how it works and what each number means.

▸ First, meet Every: Every (every.to) is a media + software company founded in 2020, with CEO and co-founder Dan Shipper. It publishes a daily paid newsletter about “the next thing in tech,” while also building its own software products — Cora, Monologue, Sparkle, Spiral mentioned in the article, plus AI courses and consulting. So “Compound Engineering” is not theoretical; it’s a method forged from the real-world experience of a company that both writes and builds, immersed in AI day-to-day.

Quick Look

• Every uses “Compound Engineering” to maintain its 5 products with essentially a one-person engineering team. The core is a Plan → Work → Review → Compound four-step cycle.

• Traditional engineering stops at Review. The fourth step, Compound, turns each solved problem into system knowledge, so AI automatically avoids similar errors next time. That’s where the efficiency gap comes from.

• This method advocates engineers spend 80% of their time on Plan and Review, and only 20% on actual coding.

• The accompanying plugin is open-source, supports Claude Code / OpenCode / Codex, includes 26 specialized agents, 23 workflow commands, 13 skills, zero-config to use.

• /workflows:review one call runs 14 specialized agents concurrently to review code. /workflows:plan with ultrathink mode can run 40+ research agents concurrently.

How One Person Manages Five Products

Every recently published a methodology called “Compound Engineering,” plus an accompanying open-source plugin, explaining how they maintain five products with essentially a single-person engineering team.

The five products — Cora, Monologue, Sparkle, Spiral, plus the website Every.to — each have basically one-person engineering teams. This scale isn’t sustained by longer hours, but by a final step in a four-step cycle that most teams skip.

◆ Why it’s worth reading: Every open-sourced what was previously internal: 14 AIs reviewing the same code simultaneously, 40+ research agents concurrently during the planning phase, plus 26 specialized agents. This is one of the most concrete open-source references for multi-agent parallel engineering practices currently available.

Why Code Gets Harder and Harder to Touch — The Root

Most codebases become harder to maintain over time for a simple reason: every new feature injects new complexity into the system, and new features have to “negotiate” with all old features. After ten years, teams spend more time fighting historical code than building new things. Code becomes harder to understand, change, and trust.

Compound Engineering flips this curve. A feature no longer adds burden to the system; instead, it teaches the system a new capability. Fixing one bug eliminates an entire class of similar bugs in the future. A solution gets solidified and becomes a directly reusable tool next time. The more iterations, the better the system gets.

The Four-Step Cycle: 80% of Time Not Writing Code

The scale is supported by a four-step cycle: Plan, Work, Review, Compound — then repeat. Whether you spend five minutes fixing a bug or several days building a feature, you follow these four steps, just allocating different time to each.

The first three steps are familiar to every developer. The fourth step, Compound, is the dividing line between Compound Engineering and ordinary engineering. Skip it, and you’re just doing “traditional engineering with AI assistance.” Traditional engineering stops at Review. Compound Engineering takes one more step — Compound — leaving what was learned this round for the next.

Counterintuitive part: writing code takes only 20% of the time. Plan and Review together occupy 80% of the engineer’s time. Actually writing (Work) plus solidifying (Compound) takes only 20%. Most thinking happens before and after code is written.

What each step does:

• Plan: Transform ideas into blueprints. Clarify requirements and constraints, research how similar features are implemented in the codebase, check framework docs and best practices, design the solution, and verify the plan is solid.

• Work: First, use git worktree (isolated sandbox copies of the repo, multiple tasks can run in parallel without interference) to create an isolated environment. The agent implements step by step per the plan, running tests, linting, and type checks after each change.

• Review: Multiple specialized agents review concurrently, tagging issues as P1 (must fix) / P2 (should fix) / P3 (nice to fix). Fixes are verified, and the problem encountered is documented.

• Compound: Extract the solution into reusable knowledge and write it back into the system — covered in detail in the next section.

A few old concepts Every suggests discarding:

• ✕ “Code must be hand-written” Your job is to produce maintainable, correct code that solves the right problem. Who types it doesn’t matter.

• ✕ “The first version should be good” In their experience, 95% of first versions are garbage, 50% of second versions are too. That’s the process. The goal is to iterate fast enough that the third version takes less time than the first.

• ✕ “You can’t learn without typing it yourself” Today, understanding matters more than muscle memory. Reviewing 10 AI implementations teaches more patterns than hand-typing 2.

• ✕ “Code is self-expression” Code was never personal. It belongs to the team, the product, and the users.

Exactly How Step 4 Works: Turning Solutions Into System Memory

The first three steps produce “a feature.” Step 4, Compound, produces “a system that gets better at building features every time.” On the ground, it’s four actions:

• Record the solution — what worked, what didn’t, what’s the reusable insight.

• Add metadata — tag with YAML frontmatter for easy retrieval later.

• Update CLAUDE.md — write the new pattern into the file the agent reads on every startup.

• Verify learning — will it automatically catch the same problem next time?

Source of compounding: Traditional development stops at step three. Compound Engineering takes this extra step — writing the just-solved problem into the system. This step doesn’t produce code; it produces the system’s ability to “automatically avoid the same type of problem next time.” The efficiency gap comes from here.

Analogy: CLAUDE.md is like an “AI operations manual” placed at the project root. The agent reads it every time it starts. It’s like the SOP for a new employee: whenever someone solves a problem that wasn’t documented before, add a rule. The next person automatically understands without stepping into the same trap.

The following comparison shows the difference this accumulation makes:

• ✕ No accumulation: The agent doesn’t know the trap. You debug, locate, and fix it together. After fixing, Compound writes “why it happened and how to avoid it” into CLAUDE.md, and saves a document with YAML tags into docs/solutions/. This time you spent extra time recording.

• ✓ System already remembers: The agent reads that rule on startup, and can also search the previous solution in docs/solutions/. So during Plan, it proactively avoids the same type of problem, never even reaching the bug. The time spent recording earlier pays back with interest.

After each Compound, CLAUDE.md gains one piece of knowledge: iteration 1 → 1 rule, iteration 3 → 3 rules, iteration 5 → 8 rules. The system gets smarter with use. docs/solutions/ accumulates into an institutional knowledge base — Every uses /workflows:compound to run this step, concurrently dispatching six sub-agents (understand the problem, extract the solution, find related old documents to cross-link, write “how to prevent recurrence”, classify tags, format into a document). Any future session can automatically reference past solutions.

14 AIs Reviewing Your Code Simultaneously

When a PR comes in, /workflows:review dispatches 14 specialized agents at once, each focusing on one dimension, then merges into a prioritized list by P1 / P2 / P3.

• security-sentinel (Security) — Scans OWASP Top 10, injection attacks, authentication and authorization.

• performance-oracle (Performance) — Catches N+1 queries, missing indexes, cacheable points, algorithm bottlenecks.

• architecture-strategist (Architecture) — Evaluates system design, component boundaries, dependency direction.

• pattern-recognition-specialist (Architecture) — Identifies design patterns, anti-patterns, code smells.

• data-integrity-guardian (Data) — Validates database migrations, transaction boundaries, referential integrity.

• data-migration-expert (Data) — Checks ID mapping, rollback safety, production data validation.

• code-simplicity-reviewer (Quality) — Enforces YAGNI, catches unnecessary complexity.

• kieran-rails-reviewer (Quality) — Rails conventions, model and controller responsibilities.

• kieran-python-reviewer (Quality) — PEP 8, type annotations, Pythonic style.

• kieran-typescript-reviewer (Quality) — Type safety, modern ES, clean architecture.

• dhh-rails-reviewer (Quality) — 37signals style: simplicity over abstraction.

• deployment-verification-agent (Deployment) — Pre-launch checklist, post-launch verification, rollback plan.

• julik-frontend-races-reviewer (Frontend) — Catches race conditions in JS and Stimulus.

• agent-native-reviewer (Agent-native) — Ensures features work not only for humans but also for agents.

Bonus explainer · N+1 query: Querying a list of 100 items, a wrong approach results in one query for the list plus 100 individual queries, 101 total requests. Like going to the supermarket for 10 items but making 11 trips — one to see what’s available, then one per item.

After deduplication, it becomes a prioritized list like:

• P1 Must fix: SQL injection vulnerability in search query (security-sentinel) / Creating user missing transaction wrapper (data-integrity-guardian)

• P2 Should fix: N+1 query in comment loading (performance-oracle) / Business logic stuffed in controller (kieran-rails-reviewer)

• P3 Nice to fix: Unused variable (code-simplicity-reviewer)

/resolve_pr_parallel handles all issues automatically — fixes P1 first, then P2, each in isolation, then you manually review. To triage first, use /triage to decide per issue.

What’s in the Plugin, How to Install and Use

The entire workflow is packaged into a plugin. Zero config to install and use. Supports Claude Code, and experimentally OpenCode and Codex.

• 26 specialized agents: Each expert in one thing — 14 review experts, plus research, design, automation, documentation types.

• 23 workflow commands: Main cycle plan / work / review / compound, plus a set of utility commands.

• 13 skills: Ready-to-use domain knowledge, like agent-native architecture skills, style guide skills.

Four directories each handle their area: CLAUDE.md (operation manual read on every agent startup), docs/solutions/ (each solved problem stored as searchable document), docs/plans/ & brainstorms/ (plan outputs), todos/ (issues with priority from review).

Install on Claude Code with two lines:

claude /plugin marketplace add https://github.com/EveryInc/every-marketplace
claude /plugin install compound-engineering

There’s also a one-shot command /lfg: you describe the feature, it chains plan → deepen plan → execute → review → fix issues → browser test → record feature demo → compound, running 50+ agents end-to-end, and produces a PR ready to merge, only pausing for plan approval.

Key Numbers: How Big Is the Concurrency Scale

• 5 — Number of products Every maintains with this method, engineering team essentially single-person.

• 80 / 20 — Plan + Review take 80% of engineer time, Execute + Compound only 20%.

• 14 — Number of specialized review agents running concurrently in one /workflows:review call.

• 40+ — Number of research agents dispatched in /workflows:plan with ultrathink mode.

• 26 / 23 / 13 — Plugin includes specialized agents / workflow commands / skills.

Every engineering effort should make subsequent work easier, not harder. —— Every, “Compound Engineering”

This article is Every’s own account of its “Compound Engineering” methodology and open-source plugin practice. The concurrency scale, time allocation, and product count are all official figures. Original: Every, “Compound Engineering”, every.to/guides/compound-engineering. Plugin open-source: github.com/EveryInc/compound-engineering-plugin.