Productizer is a free, open-source Claude Code plugin that keeps one living spec in your own repository. It runs locally in the repo you already have — no account, no server, no hosted control plane, no telemetry. One spec file at .claude/productizer/spec.md, requirements written in EARS with permanent ids that are never reused and never renumbered, a constitution of P-numbered principles above them, and every new intent classified against the whole spec as extend, refine, duplicate or contradict — where a contradiction halts the work until a human rules on it. Nine linear stages, declared checks in a committed checks.yaml, human gates on deploy and publish, and read-only generated views over the repository’s own files.
8090 Software Factory is an AI-native SDLC platform sold to regulated enterprises — and a serious one. 8090 Solutions Inc. (Menlo Park, founded 2024, CEO Chamath Palihapitiya) raised a $135M Series A led by Salesforce Ventures in June 2026, launched with an EY partnership, and sells both the platform and “8090 Enterprise”, a done-for-you build service for healthcare, insurance, financial services and federal government. Its pipeline runs Requirements → Blueprints → Work Orders → Tests → Feedback, wired by what they call a Knowledge Graph. This is an honest, architecture-level comparison, not a hit piece. These are different products for different buyers: 8090 sells a platform and a delivery organisation to enterprises under regulation; Productizer is a free plugin for a team that wants the spec to live in its own repository. Several rows below go decisively to 8090, and they are not buried.
The two agree more than a comparison page usually admits. Both write requirements the same way — 8090’s format is ids of the form REQ-[PREFIX]-NNN with acceptance criteria AC-[PREFIX]-NNN.N, phrased “When [condition], the system shall [behavior]”, which is EARS, and their own instruction is to “preserve requirement and AC IDs exactly once assigned.” That is Productizer’s rule too, and it is a point of agreement rather than a differentiator. Neither builds a coding model or a coding agent: 8090’s stated position is that “the code-gen part is BYOA - Bring Your Own Assistant and supports whatever you already use like Cursor, Claude Code etc.” — the same position Productizer takes. The real divergence is where the artifacts live (your git history versus a hosted backend), what happens when two requirements conflict, and whether there is a company behind it.
| Productizer | 8090 Software Factory | |
|---|---|---|
| Spec model | One living spec file per product, in the repo | Requirements, Blueprints and Work Orders as durable entities in a hosted Knowledge Graph |
| Requirement ids & syntax | ✓ EARS; permanent ids, never reused or renumbered | ✓ REQ / AC ids, “When… the system shall…”, ids preserved once assigned |
| Intent classified against the whole spec | ✓ extend / refine / duplicate / contradict | ✗ No published equivalent |
| Contradiction handling | ✓ Contradiction halts the work pending a human ruling | ✗ No contradiction / conflict / supersede concept in the public repo or docs; nearest is a drift alert on stale work orders |
| Principles layer above requirements | ✓ Constitution of P-numbered principles, checked first | ✗ None published |
| Where the artifacts live | Files in your repository — readable and diffable with no vendor | Hosted platform; Work Orders live in a closed SaaS backend |
| Open source | ✓ The whole lifecycle is the plugin — nothing hosted | Plugin is MIT, engine is closed — the published .mcp.json is {"mcpServers": {}} |
| Human gates you can read | ✓ PreToolUse hooks on deploy and publish, in your repo | Gates exist, but their own verify script asserts the published plugin “must not publish hook definitions” |
| Execution discipline inside a stage | ✓ Declared checks in checks.yaml; a “hollow” check blocks | ✓ Mandatory checklists — every item ends [x] or [SKIP] with a reason; no implementation files before implementation-plan.md |
| Review model | Human pull-request review; no separate delegated reviewer | ✓ Delegated review agent, six fixed dimensions, merge-base-scoped, parallel subagents, append-only rounds ending APPROVED or CHANGES_REQUESTED |
| Test-to-requirement traceability | ✓ Since v4.2.0, on the same convention: a COV_ id quotes the requirement id verbatim, so it cannot be renumbered independently and stops resolving when the requirement does — and orphans are detectable both ways. Two caveats we document ourselves: the scan is textual, so a comment or a design note mentioning a coverage id registers as coverage; and gitignored trees are skipped unless you ask for them | ✓ Tests carry COV_ ids mapped to REQ_ ids, enforced inside their platform |
| Evaluation framework | ◐ v4.2.0 shipped the apparatus: a 26-case corpus with 136 scored criteria and a matched no-plugin ablation arm, a deterministic retrieval-budget regression, an A/B harness that labels anything under five runs per arm DIRECTIONAL and refuses the conclusion, and an immutable pre-edit stage snapshot with the human delta reported separately. None of it has produced a published number: the corpus has never been graded, and the A/B harness is a scaffold that does not know how to invoke a model | ✓ Three-layer framework in a customer deployment: F2-weighted scoring, a ~50-document human-scored golden dataset, quarterly recalibration — and it is actually run |
| Independently verified efficacy numbers | None published | Figures are 8090’s own; the isolating benchmark is labelled “directional (n=1 per arm)” |
| Lifecycle stages | ✓ Nine: Plan, Design, Build, Test, Check, Deploy, Document, Announce, Maintain | ✓ Requirements → Blueprints → Work Orders → Tests → Feedback |
| Builds its own coding model or agent | No — brings your assistant | No — explicitly BYOA |
| Assistants supported | ✗ Claude Code only | ✓ Cursor, Claude Code and others |
| Lifecycle proven end to end through CI | ✗ Not yet exercised end to end | Not published; live enterprise engagements exist |
| Deployment & onboarding | Install the plugin in your repo — no account, no server, no telemetry | Platform onboarding against a hosted backend; enterprise engagement |
| Pricing | Free, MIT-licensed | Commercial platform plus a done-for-you build service |
| Funding & scale | ✗ One person’s open-source project | ✓ $135M Series A led by Salesforce Ventures; EY launch partnership |
| Support organisation | ✗ None — GitHub issues | ✓ Enterprise sales and delivery organisation, named public-sector and enterprise engagements |
| Target customer | A team that wants the spec in its own repository | Regulated enterprises — healthcare, insurance, financial services, federal government |
| What you install | Nothing native. A Claude Code plugin (/plugin install); the spec, checks and gates are files in your own repo |
An account on a hosted platform, plus a read-only GitHub App. Their public plugin is a front door — the MCP server holding Requirements, Blueprints and Work Orders is proprietary |
| Native harness work on your machine | Repo-local only — PreToolUse hook scripts you opt into via your project’s .claude/settings.json. No binary, no daemon, no login |
Little locally, because the work happens on their platform. Their own build script forbids the public plugin from shipping hook definitions at all |
Scale and support, first and plainly. 8090 has $135M, an enterprise sales and delivery organisation, a done-for-you build service, and named public engagements. Productizer has none of that: it is one person’s open-source project, not a funded platform with a support organisation. If your procurement needs a counterparty, an SLA and someone to call, this comparison ends here and 8090 wins it.
They measure their own output; Productizer does not. In one customer deployment 8090 runs a real three-layer evaluation framework with an F2-weighted score — chosen, in their words, because “missing critical information is worse than including extra information” — a golden dataset of roughly 50 human-scored documents, and quarterly recalibration. Productizer v4.2.0 ships the apparatus for something comparable — a 26-case corpus with a matched no-plugin ablation arm, a deterministic retrieval-budget regression, an A/B harness and an immutable pre-edit stage snapshot — but has published no number from any of it. The corpus has never been graded, and the A/B harness is deliberately a scaffold that does not invoke a model. A framework that has run and a framework that could run are not the same thing, and this is still a clear 8090 win.
Their review and execution discipline is genuinely strong. Review is a separate delegated agent working across six fixed dimensions — requirements alignment, blueprint alignment, architecture and conventions, tests and build health, user-facing verification, security and privacy — scoped to the merge-base diff, bucketed across parallel subagents, logged as append-only numbered rounds, ending in APPROVED or CHANGES_REQUESTED. Their execution rule is blunt and, verbatim: “CHECKLIST COMPLETION IS MANDATORY. EVERY ITEM MUST END IN ONE OF TWO STATES: CHECKED COMPLETE WITH [x], OR MARKED [SKIP] WITH A SKIP REASON. UNCHECKED ITEMS ARE EXECUTION FAILURES, NOT TODOs TO IGNORE.” And: “Do not create or modify implementation files until implementation-plan.md is written.” Their tests also carry COV_ ids explicitly mapped to REQ_ ids — a convention Productizer adopted in v4.2.0, and one place where the two now agree rather than diverge. The difference left on that row is enforcement: 8090’s runs inside their platform, where ours is a textual scan over tracked files that cannot tell a test from a comment, which we document rather than paper over.
Contradiction is a first-class stop. Every intent is classified against the whole spec, and a contradiction halts the work pending a human ruling; a superseded requirement keeps its original id and its original text. 8090 has no equivalent — both public repos and the docs contain zero occurrences of contradiction, conflict or supersede, verified with a positive control. Their nearest concept is drift: work orders going stale against blueprints, surfaced as an alert. There is also no constitution or principles layer above the requirements. Two honest caveats on our side: the symbolic cross-check scores 1.00 / 0.70 on the 21 cases we first wrote and 0.67 / 0.12 on a harder 26-case corpus — the figure tracks the corpus, and the end-to-end system’s recall is unmeasured; and Productizer runs on Claude Code only, where 8090 is assistant-agnostic.
The method does not require a platform. 8090’s Work Orders are durable entities in a closed SaaS backend. They do publish an open-source Claude Code plugin, github.com/8090-inc/software-factory-plugin, MIT licensed — but its .mcp.json is {"mcpServers": {}}, and the hosted MCP server that actually stores Requirements, Blueprints and Work Orders is proprietary, with its endpoint, auth and tool names unpublished. Their own build script fails the build if the published plugin contains names such as verification-receipt, completion-gate, validate-work-order, read_requirement, read_blueprint or Foundry, and asserts that the “Software Factory plugin must not publish hook definitions.” That is a reasonable thing for a commercial platform to do; it is stated here as fact, not as an accusation. The consequence is simply that 8090’s gates and engine are not readable by the buyer, where Productizer’s entire lifecycle is files in your repository.
On performance claims, be careful. 8090’s flagship press release says “more than 300,000 plain-English rules in 40 days”, while their own CMS case study says “100,000+” and describes the work as still under way; that CMS page carries 8090’s own disclaimer that “8090 is one of several contractors” and that nothing “states or implies that CMS endorses, partners with, or recommends 8090”; and the one benchmark that isolates their harness is the CEO’s own, published with “Results are directional (n=1 per arm).” Those are sourced facts, and the honest disclosure — the disclaimer and the n=1 caveat — is to 8090’s credit. It is also fair to say that Productizer publishes no efficacy numbers either. This row is a draw at best, not a Productizer win.
Nobody has solved process measurement. 8090 says so themselves: “We do not yet have precise metrics for alignment health… we do not have a clean way to measure the overall alignment quality of a project at a given moment, or to compare it across projects.” Productizer is in the same position, and arguably worse — its only measured numbers cover the symbolic cross-check alone, and they disagree with each other — 0.70 on the cases we wrote first, 0.12 on a harder set, and its lifecycle has not yet been exercised end to end through CI. v4.2.0 built the instruments to do better and has not yet used them: the eval corpus has never been graded, and no A/B or retrieval-budget result has been published. The one discipline it does hold is negative: a value that could not be measured is never rendered as zero — and in the scoring path that is now enforced by the wire format rather than by good intentions.
Different products for different buyers. Choose 8090 if you are a regulated enterprise buying an AI-native SDLC platform, or a build service, with a funded company, a delivery organisation, a delegated review agent, coverage traceability and a real evaluation framework behind it. Choose Productizer if you work in Claude Code, want the spec, the checks, the gates and the whole lifecycle to be files in your own repository with no vendor in the path, want contradictions to stop the work rather than surface as a drift alert, and accept that you are adopting one person’s free open-source plugin — with two disagreeing self-authored accuracy figures, an eval corpus that has never been graded, an unmeasured end-to-end system and a lifecycle not yet run through CI — rather than a supported platform.
8090 capabilities are mapped from 8090 Solutions’ own site, blog, press releases and public repository as of 2026; quoted phrases are theirs, reproduced verbatim, and nothing here states or implies that 8090 endorses, partners with, or is affiliated with Productizer or glick.run. 8090 Solutions Inc. of Menlo Park is unrelated to any similarly named venture firm. Productizer marks reflect shipped capability at the time of writing; an “✗” against 8090 reflects our reading of published material and may reflect something present but unpublished in the closed platform. Both products evolve — verify specifics against current documentation.