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. Every platform we sell runs the company first, so a release that would break a set of books breaks ours first.

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

Each of these records sits on a system we run, so we are accountable when one 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

Every system above is built, deployed and running on its own database. Checked 2026-09-09.

The systems

The six systems

Each system covers one concern, signs people in through our own identity service, has its own database and exports its data in open formats.

  • The books

    Ledger

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

    Built on
    Auth, PostgreSQL
    Data available as
    CSV and JSON

    Open Ledger Ledger product page

  • Specifications and change control

    Tracker

    Every change to every repository starts with a written specification and a ticket, and closes with a note of how it was 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 every platform on the estate, kept so that no service’s runbook exists only in one engineer’s head.

    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, so company correspondence stays 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 each release does to a working set of books.

  • A register for our own estate

    A small supplier cannot subscribe to a component inventory and security findings across its own estate in CycloneDX, SPDX and VEX, so we built a register for it.

  • We use standard foundations

    Everything above runs on PostgreSQL, FreeBSD, Python, OpenID Connect and Publicly trusted TLS. We write the application layer, and we do not write 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 unavailable. Every repository has its own runbook. Every change has a specification and a ticket recording how it was verified. Database migrations are stored inside the database they manage, so they survive a restore. Restores are tested end to end, and the whole estate is described in a published topology.

How we secure it How you leave Trust Centre

Dependencies

What each system is built on

Each row shows 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. The platforms we sell are the ones we rely on to invoice, ship and keep 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.