Productizer vs 8090 Software Factory

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.

Where 8090 is clearly ahead

They measure their own output as a matter of routine; Productizer has measured once, and found no effect. 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 — and its evals have been graded, only in one-off runs, never at publish time. The result is null. On a pre-registered 14-case hard corpus, 840 graded runs, the halt decision was correct in 235 of 280 runs with the plugin against 239 of 280 bare, Fisher p = 0.725, with the point estimate favouring bare; the skill fired in 48 of 280 plugin runs and reference files were read 0 times in 840, so the mechanism was never exercised. One case, H11, reached p = 0.0471 with the plugin worse, as one of 14 uncorrected tests, so it is descriptive only. The A/B harness is deliberately a scaffold that does not invoke a model. A framework that runs on a schedule and recalibrates, against one-off runs that found nothing, 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.

Where Productizer differs structurally

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.94 on its 33-case self-test and 1.00 / 0.90 on the 26-case corpus, in-sample because it was tuned on that corpus, and graded end to end, the halt was right no more often than the bare model; 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’s only efficacy result is a null one: its graded runs show no benefit over the bare model. 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 — the symbolic cross-check’s figures are in-sample, the graded end-to-end runs show no effect over the bare model, and its lifecycle has not yet been exercised end to end through CI. Grading is not run at publish time, 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.

The fair way to choose

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 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 in-sample accuracy figures for the symbolic cross-check, graded evals that show no benefit over the bare model, and a lifecycle not yet run end to end through CI — rather than a commercial 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.