Four years inside a compliance system. Six versions out.

The founder knew what CLEEN needed to do. Modules were already defined — Master Data, Production Data, Limit Policies, Risk Assessment. Customers were onboarding. But the interface was built top-down from vision, not bottom-up from how a QA reviewer actually moves through a cleaning lifecycle.

Screens had the right fields. The fields had the wrong relationships. A QA reviewer validating a protocol would hit six modals, three modules, and two URL schemes to answer one question: is this limit defensible?The product was growing; the mental model hadn't caught up.

The fields were right. The relationships were wrong. The product was built on storage order, not the reviewer's reasoning.

The easy diagnosis was “the UI looks dated, refresh it.” That misses the actual gap. CLEEN's screens already had every correct field — the data was complete. What was broken was the model: the interface mirrored how data was stored, not how a QA reviewer reasons toward a defensible cleaning limit. The reviewer isn't optimising for speed or delight; they're assembling an argument they can defend to an auditor. A product organised by its database schema forces them to reassemble that argument across six modals every time.

That's the reframe the whole four years ran on: in a regulated product, the interface isn't a convenience layer over the data — it's where defensibility is preserved or lost. So the design constraint was never “is this usable?” It was can a reviewer defend this live, to an auditor, without a spreadsheet open beside the screen? Every module redesign across six versions was an answer to that one question.

Version arc: v2 (2020 founder build) → v3 (Custom Reports) → v4 (On-Demand Studies, audit-trail primitive) → v5 (Validation Tracker timeline, offline studies, module rebuilds) → v6.0 (Feb 2026 structural rebuild) → v6.3 (current).

2021 → 2022 · On-Demand Studies.

Cleaning validation isn't a one-off event — verification, monitoring, bracketing, recovery, each with its own protocol structure and acceptance criteria. I designed a study-design workspace that treated the study as a first-class object instead of a one-off form.

2022 → 2023 · Validation Tracker rebuild.

The original tracker was a flat list. Real work doesn't live in a list — it lives in a timeline, across campaigns, against equipment, with approvals halfway through. I rebuilt the tracker around the validation study, with every protocol run, sample result, and sign-off linked to it. (I kept the flat list as a parallel view for one release after customer push-back; three months later customers asked for it to be removed — see Process.)

2023 onward · Offline Studies + module rebuilds.

Customers run cleaning studies on the plant floor, often without network. I designed an offline-first sampling flow that syncs back when connectivity returns, with conflict resolution and field signature capture — then rolled through the older modules: Master Data, Limit Policies, Process Train Mapper.

Feb 2026 · v6 — the ceiling raised.

Five structural shifts, not a re-skin: status-as-region (not column), analytical surfaces alongside transactional, AI-recommended worst-case selection scoped narrowly (see Process), and a cross-referencing audit portal. Eight surfaces shipped post-rebuild on the same primitives drawn in 2021 — master/instance, formula-as-UI, structured diff, status-as-region. New modules. Higher ceiling.

Four years of redesigns produced hundreds of micro-decisions. These six shaped how users think about the product — and the Feb 2026 rebuild was built on top of them, not around them. Some have industry lineage (three-level inline expansion in Linear and Notion, selection-scoped FAB in Notion and GitHub, formula-as-UI in spreadsheets). The contribution isn't pattern invention; it's the cleaning-validation adaptation — what audit-trail, defensibility, and 21 CFR Part 11 force you to change about each one.

The line that validated formula-as-UI.

For the first time I can explain our cleaning limits to my auditor without opening a spreadsheet beside the screen.

Limit Policy redesign · paraphrased from session notes

That one sentence became the bar for every later module: if the reviewer can't defend it live, it isn't done. Defensibility is the design constraint, not a QA-side checklist.

Why the team scaled the way it did.Two years solo (2021–2023) was a deliberate cadence, not a resource shortage — architectural debt required one consistent mental model to be paid down; adding designers earlier would have doubled the inputs. By the time the second designer joined in 2023, the design system was legible enough that they could take modules end-to-end without me re-explaining first principles weekly. The Feb 2026 rebuild was specced and shipped by the same designer who'd lived in CLEEN for four years — every structural shift in it traces to a pattern observed earlier: a UAT session, a customer escalation, something that failed in v3 or v4.

One small typed dropdown.Residue results have three value types — Below Detection Limit, Below Quantification Limit, or numeric. The old UI treated this as free text. A typed dropdown — numeric input only when “actual” is selected — means every downstream limit comparison knows which type it's reasoning about. A small pattern that removed an entire class of data-entry error and the audit findings that came with it.

CLEEN runs across 60+ pharma deployments and 250+ GMP facilities. Customers include nine of India's top-twenty pharma companies and multiple US/EU multinationals.

Commercial frame. Most pharma still runs cleaning validation in Excel + paper SOPs. The vendor field is shallow; horizontal QMS suites (Veeva Vault QMS, ValGenesis VLMS) treat cleaning as one of many modules with 9–24 month implementations. CLEEN is cleaning-native — the primitives are tuned for HBEL, MACO, BDL/BQL, and 21 CFR Part 11 from day one, with a 2–6 month implementation.

Scope boundary — stated plainly. What I designed is the interface layer: how the product reasons visually, what gets surfaced, what gets hidden, what order users move through, and how the system explains itself to its users and the auditors who inspect them. I did not write the core product architecture — the data model, the computation engine, the 21 CFR Part 11 signature infrastructure; those belong to the founding engineers. I did not invent cleaning validation or the regulatory frameworks CLEEN implements; those belong to FDA, EMA, ICH, WHO. The boundary is the point: the credibility of everything above depends on being precise about what I owned.

Three lessons I'd apply on day one of the next regulated-domain product:build the audit-trail primitive in year one, not v4 (two years of per-module edit histories had to be retrofitted); make defensibility the design constraint from day one (“if the reviewer can't defend the screen to an auditor live, it isn't done” was the lesson — it should have been the rule); and hire the second designer only after the system is legible — two years solo wasn't a shortage, it was the time the architecture needed to harden.