We build software for the processes your regulator audits.

For banks, insurers, healthcare providers and other licensed businesses. We start from the rules you must meet and the evidence an auditor will ask for.

What an audit asks of your software

An audit asks four things of a record: what happened, who did it, when, and whether anyone could have changed it afterwards. Most business software answers the first three poorly and the fourth not at all. Spreadsheets, email approvals and shared logins fill the gap, and those are what an auditor finds.

So we write each rule down beside the record that proves it and the report that shows it. The build is finished when every line in that register passes its test.

What you get

  • Obligations register

    Every rule the system must meet, with the record that proves it and the test that checks it.

  • Append-only audit trail

    Every change to a regulated record, with user, time and old and new values. No screen or API can edit or delete an entry.

  • Reports with their workings

    Reports in the regulator's format. Each figure traces to a saved query, so you can reproduce any past figure.

  • Access model and retention schedule

    Roles, approval steps and segregation of duties, enforced in code. Each record type has a retention period and a log showing the rule ran.

  • Evidence pack

    Test results, the access matrix, the register and the change log, ready to hand to an auditor.

When this service fits

Choose this service when a regulator, an auditor or a licence condition dictates what your software must record and report. It fits when an audit finding names a system, or when regulated work still runs on spreadsheets.

It is the wrong choice if you need someone to tell you what the rules mean. We are engineers, not lawyers. Your compliance officer interprets the regulation and we build to that reading. If an established product covers the requirement, buy it.

How the work runs

  1. List the obligations

    In the 1-week discovery we write the register with your compliance lead: each rule, its record, its report and its deadline.

  2. Design for evidence

    We design the data model, audit trail and access matrix before any screen. Each decision points to a line in the register.

  3. Build with hostile tests

    Increments ship to staging every 2 weeks. The tests try what an auditor fears: editing a log entry, approving your own transaction, reading outside your role.

  4. Walk through, then go live

    Your compliance or internal audit team checks the system against the register. We fix what they find, then hand over the evidence pack.

A typical engagement

Discovery
1 week, ends with specification and obligations register
Build length
10 to 20 weeks for a first release
Audit trail
Append-only, searchable without a developer
Handed over
Repository, tests, evidence pack, documentation, credentials
After go-live
30 days of defect fixes at no charge

Questions buyers ask

Do you certify that we are compliant?

No. That judgement belongs to your regulator and your compliance officer. We build to the register you signed and give you evidence that the system matches it.

Where is our data hosted?

In accounts you own. The specification names the hosting location, so rules on where data may sit are settled before we build. You grant our access and can remove it.

What happens when the regulation changes?

The register shows which parts of the system a rule touches, so the change is quick to scope. After go-live, a maintenance agreement can cover it.

Tell us which process is audited and we reply within 2 working days.

Start a project