What you are actually
choosing between.
If you are weighing us against a development shop, against pointing an AI coding tool at your spec, or against hiring one AI-fluent developer, this is the honest version of that comparison — what they do, what we do instead, and what the difference costs or saves you. The last section is the part most comparison pages leave out: what we don't claim.
The Spine (all audiences)
We don't generate your software. We derive it from one source of truth. The rules live in one auditable model, and the database, API, docs, and exports are all derived from it, so they can't drift.
Audience 01
vs. a Dev Shop / Agency
Comparing us to: A traditional development shop hired to build enterprise software.
In one sentence
A dev shop builds your software. We build the source it comes from, so it can't drift and you can always see where every number came from.
| Their world | Our world | What it means for you |
|---|---|---|
| Writes the rules into the database, again into the code, again into the API, again into the docs. Four copies. | Writes the rules once. Everything else is derived from them. | Your changes never get more expensive. Month one and year three cost about the same. |
| "Enterprise grade" means more process, review, and headcount to fight drift. | Quality by construction, not by discipline. | Fewer people and less process to pay for over the long run. |
| Hands you a deliverable: a codebase you now own and maintain. | Hands you the source it all derives from: one portable file. | You are never locked in. Walk away owning the thing the system is built from. |
| Rules scattered everywhere, so "where did this number come from?" is an archaeological dig. | Every value traces back to one model. | Audit any number on the system instantly. |
| Money math and permissions hand-written in many places that can disagree. | Decided once in the database; the UI is a thin client on top. | The expensive mistakes can't reach you. |
The receipts
- ADP: 60 to 80 percent of a typical build is derived, not hand-maintained.
- Delete every generated artifact, keep only rulebook.json, rebuild in a different stack, behaves identically.
- 17 substrates all 100 percent conformant from one rulebook (Postgres, Python, Go, COBOL, Excel, OWL, English).
Audience 02
vs. a Vibe Coder / "just Claude"
Comparing us to: Someone who figures they can just use Claude or a vibe coder themselves.
In one sentence
A vibe coder points the AI at the code. We point it at the model. With us, every business rule is a row, not a line of code buried where nobody can find it.
| Their world | Our world | What it means for you |
|---|---|---|
| Every rule is a line of code, smeared across the codebase. | Every rule is a row in the model. | One place to change a rule, one place to read it. |
| The rules are tangled into the executable. The only way to know what the system does is to read the code. | The rules are separated from the executable and live in an auditable model. | You can verify how it works instead of trusting a black box. |
| Ask the AI how something works and it has to dig through the whole codebase, inch-thick stacks of code, to reconstruct the rule. | Ask the same question and the AI reads one concise model that states the rule directly. | Faster, more trustworthy answers, with far less chance the AI misreads buried logic. |
| Produces a demo that works today. | Produces a durable system that gets stronger as it grows. | It doesn't rot in month six. |
| The AI is pointed at the code, so it inherits all the drift. | The AI is pointed at the model. | Change one rule and the database, API, and docs all update to match. |
| Bug surface grows with the size of the app. | Correctness floor rises as the system gets more complex. | The bigger it gets, the safer it gets. |
| Can get your outstanding-receivables number wrong and you won't know for months. | Failure modes are limited to cosmetic (a button in the wrong place). | The costly mistakes are structurally impossible. |
| Every question or change makes the AI re-read large amounts of code, burning tokens and context. | The rulebook is compact, so the AI works against a small, dense source of truth. | Lower token cost and more headroom, which matters more as AI usage grows. |
The receipts
- "A Tale of Two Claudes": naked Claude vs Effortless Claude across three increasingly complex specs.
- Token + bug curve: naked Claude grows super-linearly; Effortless Claude stays nearly flat.
- The load-bearing rules become unwritable-incorrectly, because they are data, not code.
- The rulebook is a complete spec the AI can read in full, instead of trawling the whole codebase.
Audience 03
vs. an In-House AI-Fluent Dev
Comparing us to: A buyer tempted to just hire one Claude-fluent developer in-house.
In one sentence
Everyone has the same AI now. The difference is what you point it at. Point it at code and you inherit all the drift; point it at one auditable model and you don't.
| Their world | Our world | What it means for you |
|---|---|---|
| Same AI, pointed at code. | Same AI, pointed at an auditable model. | The difference isn't the AI, it's the target. |
| Knowledge of how the system works lives in one developer's head. | Knowledge lives in a readable rulebook. | Not hostage to one person. Non-developers can audit it. |
| Drift inherited from day one. | No drift, by construction. | Stays maintainable as the team changes. |
| Their AI re-reads the whole codebase to answer "how does this work?", spending tokens to reconstruct rules that were never written down plainly. | The same AI reads one concise, auditable model that states the rules directly. | Lower token cost, and answers you can actually verify. |
The receipts
- Same receipts as above: 17-substrate conformance, ADP, delete-and-rebuild.
- The rulebook is a complete spec, sufficient for any frontier LLM to reproduce the system.
The receipts
Checked, not asserted.
17 substrates, all conformant
One rulebook produces the same answers out of Postgres, Python, Go, COBOL, Excel, OWL, and English, proven by a conformance matrix that runs on every build. "No drift" is demonstrated, not claimed.
ADP: 60 to 80 percent derived
A measurable share of a typical build is derivative (rebuildable from the source) rather than hand-written. The hand-built remainder is a thin client that holds no rules.
Delete everything, rebuild identically
Drop every generated artifact, keep only rulebook.json, and regenerate the whole system in a different framework. Conformance confirms behavior is preserved. The software is disposable; the meaning persists.
A Tale of Two Claudes
A written head-to-head (in the effortless-rulebooks repo) of naked Claude vs Effortless Claude across three specs, showing the bug and token curves diverge as complexity grows.
Where it stops
What we don’t claim.
Every comparison page is written by the side that wins it. Here is the other half — the three places this stops — so you find out now rather than in month five.
- What gets derived is the schema and business-rules core of a system — the design-time semantics. That is the part that has historically been over-engineered, and it is the part we can price by construction.
- The runtime — the user interface, the integrations, the event flows — is built on top as a thin client, and it is not regenerated. We are not claiming to regenerate your whole application down to the pixels.
- CMCC is a conjecture, not a theorem. Equivalence across substrates is verified by conformance testing on every build, not proven mathematically. That is a real distinction and we would rather you hear it from us.