← All projects

MVP ready

AuditFlow

Software that helps organizations run with less friction and clearer accountability. AuditFlow streamlines audit and compliance workflows end to end.

Compliance Audit trail Multi-tenant Go + TypeScript
Back to projects

Overview

Compliance work, with the friction removed

I'm building around a simple idea: help organizations operate better — less friction between teams, clearer accountability. AuditFlow is the first product, aimed at the audit and compliance workflows that most teams still run on spreadsheets and email.

It covers recurring engagements across the frameworks organizations actually get audited against — access certification, SOX, ISO 27001, financial, internal and vendor audits — each with its own scope, owners, evidence, and findings tracked to closure. The MVP is ready and the backend is live-verified: engagement lifecycle, scope-item review, findings by severity, and an organization-scoped audit trail all run end to end.

Stage MVP ready
Focus Audit & compliance

Architecture

Engagements, scope, and an audit trail that doesn't lie

Every audit is an engagement — access certification, SOX, financial, ISO 27001, internal or vendor — scoped down into applications or controls under review. Each scope item carries its own evidence and can raise findings, tracked by severity through to closure. Everything runs org-scoped on a Go backend with Postgres underneath, so one organization's audit data is never reachable from another's.

Engagement Access cert, SOX, ISO 27001, financial, vendor — one lifecycle core entity
↓  scoped into  ↓
Scope items Applications and controls under review this cycle per-engagement
Findings Issues raised during review, ranked by severity tracked to closure
↓
Workflow engine Draft → active → in review → complete, with valid transitions only Go backend
Evidence & audit trail Org-scoped, append-only record of who did what, when Postgres

The bet isn't the UI — it's that engagement state, scope, and evidence stay consistent by construction, so an audit read-out is never a scramble to reconstruct what happened.

Define a controlfrom the library
→↓
Collect evidenceattached & kept as an immutable trail
→↓
Review
↓outcome
✓ Metrolls straight into the audit read-out
⚠ Gap→ remediate → re-collect evidence
↓
Audit read-outproof on demand — not a scramble

Every control carries its own evidence and history — so an audit becomes a read-out instead of a fire drill.

Live UI preview

This is the real app, not a mockup

app-preview/auditflow.html

The frame above is the real AuditFlow build — same compiled CSS and component markup the product ships — loaded with fabricated engagement data. Demonstration only, not a connected environment.

Engineering challenges

What was hard, and how I approached it

01

Modelling compliance as a stateful graph

Problem

Controls, evidence, owners and approvals form an interdependent graph — a control's state depends on its evidence, which depends on tasks and sign-offs. Representing that so it stays consistent as things move is the core modelling problem.

Approach

An explicit state machine per control with typed transitions, so a control can only move between valid states and every change has a defined cause.

02

A trustworthy, immutable audit trail

Problem

In a compliance tool the record is the product — it has to answer "who did what, when" without any doubt it was edited after the fact.

Approach

Model the trail as append-only events; current state is derived from that log rather than mutated in place, so history is reconstructable and tamper-evident.

03

Multi-tenant data isolation

Problem

Every organization's audit data is sensitive; a single leak across tenants would be fatal to trust. Isolation has to be a property of the design, not a query you remember to add.

Approach

Tenant scoping enforced at the data-access layer so every read and write is bound to an org by construction, not by convention.

04

Many frameworks, one control model

Problem

SOC 2, ISO 27001 and the rest overlap heavily but describe controls differently. Modelling each separately means collecting the same evidence many times.

Approach

A shared internal control schema that frameworks map onto, so a single piece of evidence can satisfy the equivalent control in several frameworks at once.