Ship products with the coding agent you already have.

npx great-cto init

Website · One real run → · Live demo · Blog · Changelog

Русский · 简体中文 · 繁體中文 · 日本語 · 한국어 · Español · Português · Deutsch · Français

---

great_cto is the layer around the coding agent you already run. It drives your Claude Code — or OpenAI Codex — through a whole build and hands you a repository you own and a URL that already works: architecture, data model, backend, frontend, generated tests and the deploy, finished. Not a plan. Not a prototype.

It is not a hosted app builder and does not replace your agent; without one there is nothing for it to orchestrate.

Seven products built end to end in the open benchmark cost a median of $171 in tokens. You pay your own LLM provider; great_cto bills you nothing and is MIT.

You are stopped three times — on what gets built, on how, and on whether it ships. Everything between those runs unattended, and it is the pipeline's job to be worth leaving alone: 69 specialist agents (architect, design-advisor, senior-dev, code-reviewer, QA, security, devops) with an independent model checking each stage's work before the next one builds on it.

   describe a product
        │
   🤖  problem framed · options weighed · brief written
        ▼
   👤  checkpoint 1 — approve WHAT gets built
        │
   🤖  architecture · data model · screens · plan
        ▼
   👤  checkpoint 2 — approve HOW it gets built
        │
   🤖  scaffold → backend → frontend → tests → review → security
        ▼
   👤  checkpoint 3 — approve the deploy
        │
   🤖  deployed · repo · live URL

The board at localhost:3141 fills itself in — pipeline state, pending gates, per-agent cost, 30-day spend. You do not feed it; you check it.

Numbers, measured

One feature, end to end, fully traced	1h 26m · $3.40 in tokens — the receipts
A whole product — 7 built in the open benchmark	median $171 in tokens · 70/100 quality (58–86) — reproduce it
Typical month, 20 pipeline runs	~$34 — you pay your own LLM provider, nothing else
Products it knows how to build	60, across 15 US industries, through 6 reusable pipelines

The quality score is produced by running each product's own tests, not by counting files — which is why it says 70 and not a rounder, prettier number.

Quick start

npx great-cto init            # Claude Code (default) · add --host codex for OpenAI Codex

Restart your AI host, then:

/start "build a dispatch & scheduling app for an HVAC business"

The pipeline takes it from there. Day to day you touch three things:

/start "…"	describe a product or feature — the pipeline runs it
/inbox	what needs you: pending gates, P0s, blocked tasks
/digest	weekly DORA metrics + cost-per-feature roll-up

Requires Node ≥ 18.17. Companion plugins (Superpowers, Beads) install automatically. After init, verify the host actually loaded the plugin — claude plugin list --json should show no errors for great_cto.

When it asks you

One setting in .great_cto/PROJECT.md decides where the pipeline stops:

approval-level	Stops at	Per feature
product-only	what we build · whether it ships	2
gates-only (default)	what we build · the design · the deploy	3
strict	+ code review	4
auto	nothing	0

gates-only gained the product gate in v3.0.0. It used to stop on how to build and whether to release, and never on what to build — the decision that is wrong for six stages before anyone finds out. It costs one pause per product, not per feature: product-owner is an entry point and runs only from /start.

A regulated archetype — fintech, healthcare, gov — keeps its security, compliance and ship gates at every level, including auto. A lighter level delegates judgement; it never skips compliance. Full table: docs/GATES.md.

The three doubts worth having

“I can't trust code I didn't watch being written.” Neither do we, so nothing is taken on an agent's word about itself. Each stage is checked against what it actually produced — do the named files exist, do the frozen acceptance criteria pass when run, and only then is a separate model asked whether each requirement is addressed. Where that check cannot tell, it returns unverifiable, which is not a pass.

“It will spend money while I sleep.” Per-agent budgets decline to dispatch past their cap and name the number. A run whose cost could not be measured reads unmeasured and holds nothing — a limit firing on a number nobody measured is worse than no limit, and a confident $0.00 for unmeasured work is how a spend goes unnoticed.

“And then I'm locked in.” One command to install, MIT, running on your machine against your own LLM account. Delete great_cto and the repository it built is still yours — ordinary Next.js, Postgres and Stripe that any engineer can pick up.

What makes it different

• Specialists, not a generalist — 69 agents with narrow jobs and their own review gates, instead of one assistant that types faster than it thinks. The roster →
• Critics before code — architecture, spec, and schema critics run before planning, where a mistake still costs hours instead of days.
• Scope enforced at write time — an agent physically cannot touch files outside its brief. Not flagged at review; refused at write.
• QA that distrusts itself — critical paths written as Gherkin before test code, then mutation testing asks whether the suite would catch anything at all.
• Memory across sessions — decisions, lessons, and promoted patterns persist per project and globally; an interrupted run resumes knowing which stages ran.
• Cost you can see — per-agent spend, estimate-vs-actual drift, and cost-per-accepted-change on the board, not in a spreadsheet.
• Spending caps that refuse — agent-budgets: in PROJECT.md caps what a stage may spend, and the pipeline declines to dispatch past it, naming the number. An estimate never refuses: while no verdict carries a real cost the cap reads unmeasured and holds nothing, because a limit firing on a number nobody measured is worse than no limit. Set and cleared from the board.
• A stage is checked before the next builds on it — the pipeline used to hand one agent's output to the next on the strength of a line the agent wrote about itself. Now a second model (Kimi K3 via OpenRouter) checks it, cheapest question first: do the files the verdict names exist, do the frozen ## ACCEPTANCE criteria pass when run, and only then is a model asked whether each requirement is addressed. Three answers, never two — verified, rework, or unverifiable, which is not a pass: an agent that claims nothing and freezes no criteria is reported, or the cheapest way to pass becomes claiming nothing.
• Work goes back, and the return has a ceiling — a stage that fails verification returns REWORK with the findings quoted, and the agent that just ran fixes it. Distinct from BLOCKED, which means a human must decide. After three passes it stops being the agent's problem and becomes one, because two machines handing work back and forth do not get bored.
• Quality kept apart from what happened — the verdict says what a run did; a score says how well, in its own append-only store, produced by a different actor at a different time. A re-score appends rather than rewrites, several scorers can disagree about one run, and every score names who made it. An unassessed run counts as null, never zero — a pass rate divides by what was actually assessed and reports the rest beside it.
• Silence is recorded — the dispatcher writes what it decided to .great_cto/pipeline-runs.jsonl, including when it decided nothing and why. Every pipeline defect found this year hid in the gap between "nothing should happen" and "nothing could happen".

Everything runs locally, MIT-licensed, on your own keys. Your code stays on your machine; prompts go to your LLM provider and nowhere else. Telemetry is off by default (docs/PRIVACY.md).

Limitations

• For one builder — a solo founder or CTO. Two or more engineers sharing the pipeline have outgrown it.
• Not a CI/CD system — gates run locally; you still merge through GitHub Actions.
• Not certification-audited — PCI/HIPAA/SOC2 scaffolds are starting points, not certifications.
• Not deterministic — LLM output. Gate verdicts deserve a sanity check.
• Spend is measured, attribution is not yet per-agent — cost is read from the host's own session transcript rather than from an agent's self-report, so the tokens are real. But the transcript the hook is handed covers the session, not one subagent, so a run's cost can be attributed to whichever stage finished last — inflated by orders of magnitude. Treat per-agent figures as a ceiling until this is fixed. A stage with no measurement at all still shows unmeasured rather than a confident $0.00, and budgets do not fire for it.

Documentation

Docs hub → · Getting started · Gates & approval levels · Agents · Commands · Archetypes · Architecture · MCP · FAQ · Everything else — critics, jurisdictions, cost breakdown, CI, alerts

Community

Issues · Discussions · Blog · Security policy · Contributing

MIT — LICENSE. Built by @avelikiy: CTO building AI-native trading and fintech platforms; great_cto is my own loops, automated one agent at a time.

If it saved you time, a star helps other solo builders find it.

Stop being the only person who can ship.