Skip to content
Skip to main content
Novel Systems home
Calculation infrastructure

Proprietary CPQ & dispatch calculation infrastructure

Configuration software feels slow for one structural reason: the rules live on a server and the person lives at a keyboard. We moved the engine to where the question is asked. Every claim on this page is a p95 with its measurement conditions published underneath.

  • 41.8 ms

    Slowest single operation on the matrix below — the ceiling, not the average.

  • 160×

    Median speed-up across six operations against a hosted configurator round trip.

  • 4

    Runtime targets share one compiled engine, so a preview and a commit cannot disagree.

Run the engine yourselfRead the API reference
Core technology stack

Three layers, each solving a problem the one below it created

Moving computation to the client buys speed and immediately raises two questions — what happens with no network, and which copy of the truth wins. Layers two and three are the answers.

  • Layer 01 · Resolution

    Dynamic constraint solver

    A configured B2B assembly is not a form. Choosing a fascia depth invalidates three bracket options, changes the tube diameter that can carry the load, and moves the deduction that determines the cut width. The solver resolves that whole graph on every keystroke.

    8.4ms

    p95 full-graph resolution, 340-node assembly, measured in-browser

    Mechanism

    Constraints compile once into a directed acyclic graph at catalogue publish time. At configuration time the solver walks only the sub-graph downstream of the changed node, so complexity scales with what you touched rather than with catalogue size.

    • Rules are declared as data in the catalogue, not written as branches in application code.
    • Every resolution returns the reason an option was excluded, so an estimator is never shown an empty dropdown with no explanation.
    • Cycles are rejected at publish time rather than discovered as a hang in production.
    • A resolution is deterministic: the same configuration always yields the same cut list on any device.

    Without this layer

    Estimators re-derive exclusions from a printed compatibility chart, and the chart is a version behind the catalogue roughly always.

  • Layer 02 · Durability

    Offline-first sync core

    A technician in an underground loading dock has no signal and still has to complete the job. The device is the primary store. The network is an optimisation the app assumes is absent.

    100%

    of field write operations complete with the radio off

    Mechanism

    Writes land in an encrypted local SQLite journal immediately. Merge is CRDT-based per field, so a dispatcher editing a service window and a technician editing parts consumed on the same job both keep their change instead of one silently overwriting the other.

    • Last-writer-wins is used only for scalar fields a single role owns; counters and sets merge without loss.
    • The journal is append-only, so a sync that fails halfway is replayed rather than reconciled by hand.
    • Every queued payload is HMAC-signed on the device before it leaves, and rejected at the edge if the signature does not verify.
    • Conflicts that genuinely need a human — two technicians closing the same job — surface as an explicit review item, never as a silent merge.

    Without this layer

    The field app becomes a thin client, which means it is a blank screen exactly when a crew is standing in a building with no coverage.

  • Layer 03 · Locality

    Edge computation layer

    The pricing engine is compiled to a portable module and shipped to wherever the question is being asked — the browser, the field device, or the regional edge node. A quote does not need a round trip to a central region to know what it costs.

    0 round trips

    network calls required to reprice a line item

    Mechanism

    One engine, three deployment targets. The same compiled module runs client-side, on the edge worker, and inside the server action, so a price computed in the browser and a price recomputed at commit are produced by identical code rather than by two implementations that agree until they don't.

    • Server-side recomputation on commit is authoritative; the client figure is a preview that is verified, never trusted.
    • Catalogue and rate tables are content-addressed, so an edge node can prove it is pricing against the published revision.
    • A total network outage degrades the product to quoting-only. It does not degrade it to nothing.
    • No calculation depends on a third-party API being reachable at the moment of quoting.

    Without this layer

    Every dimension change becomes a network round trip, and the quoting desk's throughput becomes a function of your ISP.

Performance benchmarks

The gap is architectural, not incremental

Our slowest operation completes in 41.8 ms. The fastest modelled cloud round trip takes 0.89 s. No amount of server tuning closes a gap created by the speed of light and a TCP handshake — you have to stop making the trip.

Calculation latency, p95

Same operation, edge engine versus a hosted configurator round trip

Novel edgeCloud ERP

  • Resolve compatible options

    One dimension changes; every downstream option list is re-derived.

    148× faster
    Novel edge
    8.4 ms
    Cloud ERP
    1.24 s

  • Reprice a configured line

    Fabric, hardware, labour, and freight recomputed against the rate table.

    128× faster
    Novel edge
    11.6 ms
    Cloud ERP
    1.48 s

  • Derive the manufacturing cut list

    Tube, hembar, and fabric sizes from finished width with deductions applied.

    339× faster
    Novel edge
    6.2 ms
    Cloud ERP
    2.10 s

  • Enforce the margin floor

    Line, quote, and approval thresholds evaluated together.

    287× faster
    Novel edge
    3.1 ms
    Cloud ERP
    890.0 ms

  • Recalculate a 60-line quote total

    Full document reprice including HST and line-level rounding.

    151× faster
    Novel edge
    41.8 ms
    Cloud ERP
    6.30 s

  • Score a technician against a job

    Skill tags, certification expiry, van inventory, and drive time.

    170× faster
    Novel edge
    9.7 ms
    Cloud ERP
    1.65 s
How these numbers were measured
  • Percentiles are p95 over 10,000 runs, not means.
  • Edge figures are measured in-browser on a 2021 mid-range laptop, cold cache, throttled to 4× CPU slowdown.
  • Legacy figures model a hosted ERP configurator round trip on a 40ms RTT connection: request, queue wait, server-side rule evaluation, database read, response, re-render.
  • The legacy model is an architectural comparison, not a benchmark of any named competitor's product.
One engine, four runtimes

The same compiled module everywhere a price is produced

Most platforms end up with a fast client estimate and a correct server total, and spend the next three years reconciling them. There is one implementation here, so the question never arises.

  • Estimator browser

    01

    WebAssembly + TypeScript

    The full engine ships to the quoting desk. Configuration is interactive at typing speed because nothing leaves the tab.

  • Field device

    02

    Embedded SQLite + native bridge

    The same module runs against the local journal, so a technician can price a change order in a basement.

  • Regional edge node

    03

    V8 isolate, ca-central-1

    Public quote links and partner API traffic are priced at the edge nearest the caller, inside Canadian residency.

  • Origin server action

    04

    Node.js, ca-central-1

    The authoritative recomputation on commit. If it disagrees with the client preview, the client preview loses.

Motorised hardware provisioning rides the same path: 3 hardware vendors receive their addressing payloads generated from the record that priced the job. See the integration catalogue.

Benchmarks are easy to publish and easy to doubt

Open the CPQ sandbox and change a dimension. The number that comes back is produced by the engine described on this page, running in your browser, with your network tab open.

Open the sandboxTalk to an engineer