Skip to content

How we run

We run the company onwhat we sell.

Our books, specifications, bill of materials and SBOM, commercial record and email all run on systems we wrote and operate. The platforms we sell run the company first. A release that would break a set of books breaks ours before anyone else's.

production databases, each owned by one service
22
database hosts
4
countries
3
minutes recovery point on the managed fleet, at most
5

Comparison

What we use for each concern

We run the systems behind these records ourselves and are accountable when a record is wrong.

Each concern, what organisations usually buy in for it, and the system RODMENA runs
ConcernUsually bought inWe run
The booksAn accounts subscriptionLedger
Specifications and change controlA hosted issue trackerTracker
Bill of materials and SBOMA spreadsheet, if anythingProvenance
The commercial record (CRM)A sales subscription, separate from the accountsTrace
Documentation and runbooksA documentation subscriptionKnowledge base
Company emailA mail and office subscriptionWebmail

All the systems above are built, deployed and running on databases of their own. Checked 2026-09-09.

The systems

The six systems

Our systems cover one concern apiece, sign people in through our own identity service and export data in open formats from separate databases.

  • The books

    Ledger

    Double-entry accounting for money, credits and stock. It keeps our books and is the service we sell.

    Built on
    Auth, PostgreSQL
    Data available as
    CSV and JSON

    Open Ledger Ledger product page

  • Specifications and change control

    Tracker

    Changes to our repositories start with a written specification and a ticket, and close with a note of how they were verified.

    Built on
    issuedb-cli + EARS, Identity
    Data available as
    JSON, and the ticket database committed in each repository

    Open Tracker

  • Bill of materials and SBOM

    Provenance

    An asset register for the hardware, an SBOM for every software release we ship, and security findings tracked against both.

    Built on
    Auth, PostgreSQL
    Data available as
    CycloneDX, SPDX and VEX

    Open Provenance Provenance product page Sign-in required

  • The commercial record (CRM)

    Trace

    Customer relationship and revenue records, reconciled against the ledger.

    Built on
    Ledger, Auth
    Data available as
    CSV and JSON

    Open Trace Trace product page Sign-in required

  • Documentation and runbooks

    Knowledge base

    Documentation for the platforms on the estate, including the runbooks for our services.

    Built on
    Auth, TokenGate
    Data available as
    Markdown and JSON

    Open Knowledge base Sign-in required

  • Company email

    Webmail

    A mailbox interface over our own mail platform that keeps company correspondence on infrastructure we operate.

    Built on
    RODMENA Mail API, Identity
    Data available as
    IMAP and mbox

    Open Webmail Sign-in required

Inside

The Provenance register

Four screens from Provenance: the hardware asset register, the evidence pack organised by control reference, the findings table with VEX positions, and the component explorer.

Four screens from the Provenance bill-of-materials platform. An asset register listing every device the company holds with its state, custodian and encryption status. An evidence export pack organised by control reference, with sections for Cyber Essentials and for ISO/IEC 27001:2022 Annex A, each stating what the register evidences and what it does not. A findings table listing vulnerabilities by severity with their CVSS score, the component and release affected, whether that release is deployed, and its VEX assessment. A component explorer that looks a component up across the whole estate by package URL.
Provenance, our bill-of-materials platform, in use. We built it for the evidence pack. When a buyer asks which components a release contains and which advisories affect them, we answer with an export.

Build or buy

Why we build our own

For most of these systems, buying one in would make little sense.

  • We already sell it

    The ledger that keeps our books is one of the products on this site. Paying someone else for an equivalent would be odd, and running it ourselves shows us what a release does to a working set of books.

  • A register for our own estate

    We wanted a component inventory and security findings for our own estate in CycloneDX, SPDX and VEX, under our own control, and built a register to hold them.

  • We use standard foundations

    Everything above runs on PostgreSQL, FreeBSD, Python, OpenID Connect and Publicly trusted TLS. We write the application layer but not our own databases, operating systems or cryptography.

Key-person risk

A company that runs its own systems has to cope with the people who built them being away. Our repositories have runbooks, and changes have a specification and a ticket that records how they were verified. Database migrations are stored inside the database they manage and survive a restore with it. We test restores end to end, and a published topology describes the whole estate.

How we secure it How you leave Trust Centre

Dependencies

What each system is built on

The rows show a concern, the system that handles it, and the platforms from our own catalogue that it runs on.

  1. The books

    Ledger

    Auth, PostgreSQL

  2. Specifications and change control

    Tracker

    issuedb-cli + EARS, Identity

  3. Bill of materials and SBOM

    Provenance

    Auth, PostgreSQL

  4. The commercial record (CRM)

    Trace

    Ledger, Auth

  5. Documentation and runbooks

    Knowledge base

    Auth, TokenGate

  6. Company email

    Webmail

    RODMENA Mail API, Identity

The right-hand column comes from our own product catalogue. We use the platforms we sell to invoice, ship and keep our records. See how the platforms fit together.

Arrange a walkthrough

We can take you through any of these systems, or send the topology, policies and capability statement for your procurement pack.