sf-intelligence vs dx0

At a glance

They are aimed at different people

dx0's own site names its audience: Salesforce platform owners, business-applications leads, RevOps managers, implementation partners, product managers. Those are largely people who will not install a Node package or authenticate a CLI, and for whom a browser tab is the correct interface. Its features follow from that — automatic change capture so nobody has to maintain a repository, a knowledge hub so an answer one person got is reusable by the next, full-text search across the org for people who do not know the metadata names.

sf-intelligence is aimed at developers and at the AI coding agents they run. It has no browser interface at all. It is a stdio MCP server plus a CLI, and its natural home is Claude Code or Cursor sitting next to the repository you are about to change. That is a narrower audience, and it is a deliberate trade: a tool with no UI is cheap to ship, easy to audit, and useless to a stakeholder who wanted a link.

The consequence for a buying decision is simple. If the people who need answers are not developers, a hosted product wins on adoption regardless of what the feature table says. If the people who need answers are agents in an editor, an MCP server wins because it can be called mid-task without a human copying anything between windows.

Pricing and licensing models

dx0 is a commercial per-seat subscription. Its changelog entry dated 28 May 2026 states that dx0 is moving to €85 per user per month for new customers, effective that day, with existing customers' rates unchanged until 1 June 2027. There is no public self-serve price list beyond that; the site offers a free trial on request. Per-seat pricing is predictable and easy to expense, and it comes with a vendor who is contractually on the hook — including the ISO 27001 certification and GDPR posture that procurement will ask about.

sf-intelligence is free and source-available under MIT + Commons Clause. It is deliberately not described as open source: the Commons Clause withholds the right to sell the software itself as a service. Practically, you may run it, read it, modify it for internal use and audit exactly what it does with your metadata; you may not resell it as a hosted product. The details are on the licensing page. Nothing is metered, so there is no per-seat maths — but there is also no vendor to escalate to at 2am, which is a real cost, just not a cash one.

Worked example: a picklist you are about to change

You want to add a value to Widget__c.Status__c and you need to know what already depends on the current value set. A hosted natural-language tool answers this as a narrative — readable, shareable, generated by a model over its ingested view of your org. sf-intelligence answers it as a set of cited claims produced by deterministic rule matching over the local graph:

› what depends on Widget__c.Status__c?
▸ CustomField:Widget__c.Status__c — picklist, 4 values
  Flow "Widget_Router" — decision on Status__c  [declared]
  ValidationRule "Widget_Status_Required"          [declared]
  ApexClass "WidgetService" — reads Status__c     [parsed]
  Layout "Widget Layout" — required field        [declared]
  coverageCaveat: dynamic SOQL and reflective field access not visible

The bracketed tier is the point. declared means the reference is stated in the metadata; parsed means it came from an AST pass over Apex; heuristic means a pattern matched and you should check. When a verdict rests on absence — "nothing else references this" — a coverage caveat names what was not checked, so absence is never presented as proof. That mechanism, and why it is a rule engine rather than a language model, is described in the deterministic reasoning model write-up.

Neither shape is universally better. A narrative is more useful in a document; a cited list is more useful when the next step is a deployment and somebody will ask you how you know.

Choose sf-intelligence when you want to…

• Keep org metadata off third-party infrastructure entirely — the vault is a directory on your disk
• Call tools from Claude Code, Claude Desktop or Cursor mid-task, without leaving the editor
• Run impact, permission-cascade, code-quality and exposure analyses where every claim carries a component ID and a confidence tier
• Avoid per-seat cost across a large team, or spend nothing at all while evaluating
• Guarantee no write path — the product cannot deploy, edit or delete anything

Choose dx0 when you want to…

• A hosted interface non-developers will open without being talked into it — no Node, no CLI, no local vault to refresh
• ISO 27001 certification and a vendor security pack to hand to procurement
• Automatic change capture with before/after comparisons and no git or manual configuration
• A team-shared knowledge hub, so one person's investigation becomes an article the next person finds
• Org-wide full-text search for people who do not already know the metadata API names
• Someone else to be accountable for uptime, freshness and support

When not to use sf-intelligence

• You need it to change something. There is no deploy, edit or delete path. It explains; a human or a DevOps tool acts.
• The audience is not technical. There is no web UI and no shareable link. If the answer needs to land with a stakeholder, a hosted product is the better tool and pretending otherwise wastes everyone's time.
• You need freshness without effort. The vault is a point-in-time snapshot; it is stale the moment someone edits the org, and only a refresh fixes that. Automatic continuous change capture is exactly what a hosted service is good at.
• You want the answers kept as team knowledge. Nothing is persisted for colleagues — output lives in one chat session unless you paste it somewhere.
• You need business record data. The vault holds metadata. An opt-in, consent-gated read-only live plane can return capped counts and samples, but this is not a reporting tool.
• You need a support contract. There is no SLA. If an answer is wrong you read the source or file an issue.

Try both — ours needs no org

dx0 offers a free trial on request. sf-intelligence needs nothing at all: no Salesforce org, no authenticated sf CLI, no configuration. One command serves a built-in synthetic org — "Verdant Energy", a fictional solar installer — over MCP, fully offline:

claude mcp add --transport stdio --scope user sf-intelligence-demo -- npx -y sf-intelligence demo

Ask the demo org a delete-impact or sharing question and judge the citation discipline on fabricated metadata before deciding whether to point anything at production. When you are ready, connecting a real org is a single read-only retrieve.

More comparisons

If your requirement is a scored audit and ecosystem benchmarking rather than conversational analysis, Hubbl is the closer fit. If you also want an official first-party option for live data and DevOps, see Salesforce's own MCP servers — many teams register those alongside sf-intelligence. Related reading: impact analysis before deployment. Full set: compare hub · Elements.cloud · Metazoa · Sweep.