Pre-launch. Not deployable to production. This page states what the tests prove and what is missing — nothing else.

A customer hub starts with CRM code you own

One commercial record chain, from lead to service

People ask this as: customer hub with a single customer view across crm, marketing, delivery and billing

Accordo gives coding agents a deterministic CRM foundation for the commercial journey the application already controls: lead, opportunity, quote, order, contract, delivery and service. Each transition is explicit, audited and test-backed. This is one local chain of application records, not an identity-resolved profile assembled from other systems; marketing, billing and a unified customer screen remain outside the runtime.

Where this stops

Read this before the rest of the page. Every line below is a thing this does not do.

  • This page describes a buildable CRM foundation, not a ready-made Customer Hub product. The commercial chain is merged in slices, and each slice keeps the boundary stated below.
  • Single customer view here means records written through this application's audited actions, CRUD routes and module services in one local database. It is a chain, not a profile assembled from other systems: nothing ingests, deduplicates, merges or resolves an identity.
  • This is not a customer data platform, and nothing here softens that refusal. The comparison page states it in full and this page inherits it; no product in that category is named, because the competitor research this site may cite carries none.
  • Marketing and billing do not exist as runtime code, and there is no unified customer screen. The Admin navigates by module and domain; no view, query or timeline assembles one customer's chain for a reader.
  • None of it is deployable. No authentication, tenancy or RBAC, SQLite only, no scheduler and no integration adapter — so a hub that works here works on one developer's machine.
  • Nothing here is measured against another product, and no page on this site ranks this against a named vendor. The build benchmark has not been run.

No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network. Every claim and every limitation is on one page.

Working record chainOne customer, six connected operating recordsStored identifiers carry provenance forward. They do not ingest or reconcile an identity from another system.
  1. Validated path Lead intelligence Capture, qualify, enrich, score and route under versioned policy.
  2. Validated path Company · Contact · Opportunity Convert atomically, then advance the deal through server-owned pipeline actions.
  3. Validated path Quote · Approval · Order Price on the server, gate discounts and freeze immutable commercial evidence.
  4. Partial domain Contract · Subscription Activate operational terms and lines from the signed Order snapshot.
  5. Partial domain Delivery Handover work, record execution and economics, govern change and acceptance.
  6. Partial domain Service Activate entitlements, record support cases and retain elapsed-time SLA evidence.

Start from a CRM foundation that already runs

A reader who typed customer hub or single customer view is asking for something wider than CRM, and the honest first answer is the narrower word. CRM is the part of this framework that is merged and proved: a lead is captured, scored, routed, qualified and converted into a Company, a Contact and an Opportunity through explicit actions, each one atomic and audited (C-06); that opportunity moves through code-first pipeline stages under a server-authoritative action (C-05); a quote is priced on the server from a catalog, and a discount that crosses the policy threshold stops and waits for a named human, with an agent actor refused a 403 (C-08, C-21). Everything wider on this page is measured against that, and none of it replaces it.

The job catalogue is the arbiter for every status below, not this page. Of the seventeen rows in the core CRM section of docs/benchmarks/jobs.json, eight read validated end to end, four partially supported and five not supported. That file is generated from docs/benchmarks/CRM_JTBD_MATRIX.md and held in step with it by tests/jobs-json.test.js, which also asserts that every test named as evidence still exists on disk — so a status quoted here is checkable rather than asserted.

One commercial chain, not an identity graph

Single customer view, on this page, means the records this application's audited actions, CRUD routes and module services wrote about one customer in one local SQLite database, each carrying the id of the record it came from. A Contact and an Opportunity carry the companyId the conversion action wrote, checked against a Company that exists. A Commercial Contract carries orderId, quoteVersionId, opportunityId and companyId, copied from the immutable Order rather than read back from a live catalog. A Delivery Project and a Service Coverage each carry contractId, orderId and the companyId the contract recorded. A Support Case carries the coverage and the entitlement it was recorded against. Following one customer means reading those ids.

It is a chain this system wrote, not a profile it assembled. Nothing here builds one profile per person or account out of records held in other systems, because this framework has no pipeline that ingests records or events from external systems: there is no imported identity set to resolve, and no resolution step exists to do it with. Records can still be created through the framework's audited CRUD and service APIs; that is local application input, not cross-system ingestion. Two records for the same human stay two records forever. Detecting duplicates on import or entry (JTBD-DO-02), merging two Companies or Contacts (JTBD-DO-03), searching across modules (JTBD-DO-07) and seeing a unified activity timeline for a record (JTBD-DO-08) all read not supported, and there is no import or export of any kind (L-06).

This page adds nothing to the customer data platform question and takes nothing away from it. Not a customer data platform states that refusal in full, and this page inherits it rather than re-arguing it in softer words: a platform of that kind ingests records and events continuously from many source systems, resolves them into one profile per person or account, and builds segments over those profiles that can be frozen, suppressed and synced to a destination. None of those three exists here in any form. The word hub on this page never reaches for any of them, and no product in that category is named anywhere on this site, because the only competitor research it may cite carries no research on them at all.

There is no screen for it either. The Admin navigates by module and by domain — generated modules, pipeline boards, Quotes, Contracts, Delivery, Service — and carries no per-customer page anywhere in it. A single customer view here is a property of how the records reference each other, not a view somebody opens; and every one of those ids is managed storage written by the action that created the record, never a value a client supplied.

Each operating domain has a precise boundary

CRM and lead intelligence — merged, several jobs validated end to end. Capturing, qualifying and converting a lead (JTBD-04, JTBD-05, JTBD-05b) and moving a deal through pipeline stages (JTBD-03) read validated end to end, as do enrichment with snapshot and provenance, explainable scoring, automatic routing under a published policy, and policy versioning (JTBD-LI-01, JTBD-LI-02, JTBD-LI-04, JTBD-LI-07). Four further lead rows read partially supported, and manual reassignment with permission and reason (JTBD-LI-06) reads not supported. Where it stops: the enrichment provider is a checked-in fixture with no external data source wired, routing targets are application identifiers rather than authenticated users, and the Lead model belongs to the starter rather than to the framework core.

Quote, discount approval, signature and order — merged, several jobs validated end to end. Creating a quote from a price book (JTBD-CO-01), requesting a discount under a deterministic policy (JTBD-CO-03) and creating an immutable signed Order snapshot (JTBD-CO-07) read validated end to end; synchronising an external catalog, obtaining the required commercial approval and the two signature rows (JTBD-CO-02, JTBD-CO-04, JTBD-CO-05, JTBD-CO-06) read partially supported. Where it stops: every catalog and signature provider is an offline fixture, no envelope has ever been sent to a real signer, the signed document is canonical JSON rather than a PDF, and the phrase quote-to-cash stops at the quote.

Contract and subscription — merged, partial. Activating a commercial contract from a signed Order and activating a subscription with lines and an initial term (JTBD-CS-01, JTBD-CS-02) read partially supported. The other eight rows in that section read not supported: amending seats or quantity, recording an expansion or contraction, calculating MRR, ARR and TCV from real contract data, scheduling a renewal, creating a renewal opportunity, applying an uplift policy at renewal, cancelling or non-renewing with an audited reason, and reading a complete amendment history. Where it stops: the term was never signed, so effective date, term dates, auto-renew and notice period are operational metadata a human typed in with a required reason — and there is no scheduler, so a notice period passes without anything firing (L-04).

Delivery and service — merged, partial. Handing a won deal to delivery, tracking hours and costs, and managing a change request with impact and approval (JTBD-DS-01, JTBD-DS-06, JTBD-DS-08) read validated end to end; seven further rows read partially supported, including activating a service contract with entitlements and SLA (JTBD-DS-11) and managing support cases and escalation (JTBD-DS-12). Restricting partner access to assigned work (JTBD-DS-04) and activating billing on accepted milestones (JTBD-DS-10) read not supported. Where it stops: nothing schedules, staffs or computes percent complete; customer acceptance is testimony a user actor recorded rather than an authenticated customer's signature; the SLA clock is elapsed wall-clock minutes with no business-hours calendar and no pause; and nothing escalates, routes or notifies by itself.

Marketing, billing and ERP remain separate

Marketing is a design document, not code. All 43 marketing rows in the job catalogue read not supported — audiences, consent and suppression, campaign proposals, one-shot, rolling and triggered sends, multi-step journeys, content and landing-page generation, experiments and holdouts, paid media, funnel definitions and every attribution model. docs/strategy/MARKETING_GROWTH_OPERATIONS.md opens by saying so itself: product strategy and roadmap only, nothing in it implemented, and no package under packages/marketing, packages/journeys, packages/experimentation, packages/content or packages/attribution exists. The roadmap sequences the work as track MK0 to MK7 and none of it is merged, so nothing on this site describes a marketing capability, in any tense (L-11).

Billing does not exist in any form. There is no invoice, no payment, no dunning, no tax, no usage rating, no proration and no revenue recognition anywhere in the repository, and MRR, ARR and TCV are not derived from contract data. Activating billing on accepted milestones (JTBD-DS-10) and calculating MRR, ARR and TCV from real contract data (JTBD-CS-05) both read not supported. The subscription module's own description states what it is instead: a commercial activation record, not a billing engine, with no invoice schedule, usage rating, proration, payment, renewal or cancellation state. docs/strategy/EXECUTION_ROADMAP.md lists invoicing, billing, payment, usage rating, proration, tax and FX as explicitly deferred (L-10).

ERP is not a goal either, and docs/strategy/RECOMMENDATION_MAP.md says to say so plainly rather than leave it open. The closest thing to a money figure that does exist is deliberately not one: delivery records append-only time and expense evidence costed by a versioned policy and returns a delivery contribution estimate grouped by currency, which is not a margin, not revenue and not an accounting figure — and a project carrying any recurring obligation returns no estimate at all, with a named reason (C-12).

The boundary every build still inherits

None of the above changes what the framework is. There is no authentication, tenancy or RBAC, persistence is local SQLite, there is no scheduler, and no integration adapter sends anything to anyone — so a hub composed here is a hub on one developer's machine. Real customer data does not belong in it: there is no export and no erasure path, so a data-subject access or deletion request cannot be serviced with it (L-09). Enforcing team or tenant permissions (JTBD-15) reads not supported, which is the same fact stated by the catalogue.

The evidence this page rests on

Claims and limitations are printed from site/claims.json word for word. Job statuses come from docs/benchmarks/jobs.json; a job with no page of its own is listed with its status rather than linked.

Claims

  • C-06 A lead is captured, scored, routed, qualified and converted into Company, Contact and Opportunity through explicit actions, each one atomic and audited.

    LimitEnrichment runs against a fixture provider — no real external data source is wired. The Lead model is the starter's, not a built-in core module.

  • C-05 Opportunities move through code-first pipeline stages under a server-authoritative action — the client asks, the server decides.

    LimitPipelines are proven on the built-in Opportunity module. Configurable pipelines for generated custom objects are not claimed.

  • C-08 Quotes price on the server from a catalog — one-time and recurring, flat, per-unit, volume and graduated tiers — and freeze into an immutable version when a discount goes for approval.

    LimitCatalog sync runs against a fixture provider; no real external catalog (Stripe, Zuora, ERP) is connected. Money is integer cents with no FX — currencies are never summed.

  • C-21 The same refusal holds where the money is: an agent actor asking to approve a discounted quote is refused with a 403, and only a human user actor can decide.

    LimitThe assertion lives inside a composite end-to-end test rather than a test named for it, so the citation is a file and a line rather than a test name. Extracting it into a named test is tracked in docs/strategy/GO_TO_MARKET.md; until then, cite the line.

  • C-09 A signature envelope produces verified events and a hashed signed artifact, and exactly one immutable Order is built from the approved quote version.

    LimitA fixture signature provider with a test-only webhook key. No DocuSign, Adobe Sign or Dropbox Sign adapter exists, and the artifact hash is provider-reported rather than independently recomputed.

  • C-10 A signed Order activates into a Commercial Contract, an immutable contract version, a Subscription and explicitly pending delivery and service obligations — every component classified, never guessed.

    LimitThe term is post-signature operational metadata, not a signed contractual term. Nothing bills, renews, amends or cancels: there is no scheduler, so auto-renew and notice periods are recorded and never fire.

  • C-11 Pending obligations hand over into a Delivery Project with work packages, milestones and an optional partner — atomically, idempotently, and across a package boundary the kernel never learns about.

    LimitIt hands work over and runs it through human-driven transitions. Nothing schedules, staffs, computes percent complete or bills. Deliverables and recorded customer acceptance exist as of M14b2, and acceptance there is evidence a user actor recorded — never an authenticated customer, a legal signature or authorization to bill.

  • C-12 Delivery records what it consumed: append-only time and expense evidence, costed server-side by a versioned fingerprinted policy, with a reproducible contribution estimate grouped by currency.

    LimitDeliberately not a margin: no revenue recognition, no cost of goods sold, no ARR/MRR/TCV, no annualization, no FX. A project carrying a recurring obligation returns no estimate at all and says why.

  • C-16 Every mutation goes through a module service or a named workflow, and leaves an audit event and a step-level trace behind it.

    LimitAudit records what the process did under an asserted actor. It is not a tamper-evident or externally attestable log, and it is not a compliance control.

Limitations

  • L-01 No authentication, tenancy or RBAC. The server is local-development-only. An actor header is an assertion, not an identity. Do not expose it to a network.
  • L-04 No scheduler, no task engine, no reminders. One follow-up Task is created inside lead qualification. There is no recurring work, no delayed workflow, no queue — so nothing fires on a renewal notice period either.
  • L-05 No email, calendar or marketing integrations. An in-memory notification provider contract exists. No adapter sends anything to anyone.
  • L-06 No import, export, dedupe, merge, bulk edit, saved views or global search. Table stakes in every commercial CRM, and none of them has a milestone yet. This is recorded deliberately rather than left for you to discover.
  • L-08 Ownership today means copying source, not installing a dependency. There is a project bootstrap and there is no published package, and the two are different facts. The repository's bootstrap command scaffolds a project that boots, reports `valid` from `app inspect` and exits 0 from `project doctor`, offline and with no install — run from a checkout of this repository. The package published under the reserved npm name is still an empty 0.0.1 placeholder, so the `npm create` route installs nothing until a human publishes it. Either way the framework is vendored into the project rather than depended on by version: you own the result outright, and upgrading means merging, not bumping.
  • L-09 You cannot put real customer data in this yet. A CRM is a personal-data system by definition, and this one has no authentication, no tenancy, no export and no erasure path — so there is no way to service a data-subject access or deletion request with it. Data governance is designed and unimplemented. The one thing that does hold today: lead scoring is deterministic, versioned and explainable, not a model's judgement about a person.
  • L-10 Nothing bills. No invoice, payment, tax, usage rating, proration or revenue recognition exists, and MRR, ARR and TCV are not derived from contract data.
  • L-11 Marketing is a design document, not a package. All 43 marketing jobs read 'not supported', no marketing package exists, and the strategy document says nothing in it is implemented.

Jobs it covers

Documented in

Proved by