Skip to content

Investors

Building the Clinical Data Automation Layer.

Clindaddy addresses labor-intensive clinical-data workflows at multiple points in the clinical-trial lifecycle. The initial wedge is a single, well-bounded problem; the expansion follows the data downstream.

Illustration of the clinical data lifecycle running from protocol through FlashEDC, data collection, and FlashAnalysis to submission.
Illustration. One lifecycle, two engines — the shape of the platform thesis.

Investment thesis

A narrow wedge, then the same model downstream.

The expansion story is not a second product line. It is the same study continuing through stages that are already effort-heavy and already specification-driven — and, further out, the same neutral study model projected into the systems a trial runs on.

Initial wedge

FlashEDC

Protocol to EDC study design and data capture.

The narrowest, most repeatable problem in the lifecycle: turning a protocol into a study design, then capturing the data against it. It has a clear input, a reviewable output, and a measurable cost today.

Downstream expansion

FlashAnalysis

Clinical data → standards → analysis → QC → submission.

The same data continues into SDTM, ADaM, TLFs, QC, and submission artifacts. Each stage is effort-heavy and specification-driven, which is what makes it automatable. Beyond the lifecycle, the same neutral study model is what is architected to project into the wider systems a trial runs on — RTSM, eSource, CTMS, eTMF, ePRO, eCOA, and eConsent.

Long-term platform

One canonical study model, projected into the systems a trial runs on.

The protocol is read once into a system-neutral study model. Today it projects into EDC and the data capture that follows, and downstream into standards, analysis, QC, and submission. The same model is architected to project into the wider systems a CRO operates — RTSM, eSource, CTMS, eTMF, ePRO, eCOA, and eConsent — of which only EDC is built today.

  1. Protocol
  2. Study Build
  3. Data Capture
  4. SDTM
  5. ADaM
  6. Analysis
  7. QC
  8. Submission

Current technology position

Working technology with a clear path toward productization.

Clindaddy's products are working technology, not finished commercial SaaS. FlashEDC is in internal use as a CRO tool; FlashAnalysis is a tested, policy-driven platform.
FlashAnalysis~2,500 passing tests
The current FlashAnalysis codebase is covered by approximately 2,500 passing tests, alongside a policy-driven approach to governing real versus synthetic data.
FlashEDCWorking internal CRO tool
FlashEDC is a working internal CRO tool with strong engine fidelity. It currently depends on a specific EDC environment.

Internal engineering metrics describe code health and coverage. They are not evidence of commercial traction, and we do not present them as such.

Diligence

The questions we expect, answered in the open.

These are the answers as they stand today. Where something is not yet established, the answer says so.
01

What problem is being solved?

Manual translation work across the clinical-data lifecycle: protocol to study design, collected data to standards, standards to analysis, analysis to submission artifacts.

02

Why is the problem valuable?

The work is high-volume, high-consequence, and repeated per study by every sponsor and CRO. Errors are expensive and late-stage corrections are more expensive still.

03

Why is this difficult?

Clinical work cannot be fully autonomous. It requires deterministic execution, independent QC, human approval, and traceability — constraints that rule out the obvious approaches.

04

What technology exists?

A working FlashEDC internal CRO tool with strong engine fidelity, and a FlashAnalysis platform covered by approximately 2,500 passing tests with policy-driven provenance governance.

05

What differentiates Clindaddy?

AI assists with interpretation; deterministic engines execute; humans approve; everything is traceable. Trustworthy automation rather than an AI wrapper.

06

What is the expansion opportunity?

One protocol read becomes a system-neutral study model. The same model that projects into EDC is what projects into RTSM, eSource, CTMS, eTMF, ePRO, eCOA, and eConsent — so expansion is the same model reaching more systems, not a new product line. Only EDC is built today.

07

Who could buy it?

CROs looking to reduce study-build and programming effort, and pharma and biotech sponsors looking for speed, reproducibility, and submission readiness.

08

What is the path to a larger platform?

Prove further projections of the same neutral model — beginning with RTSM, which is in development, then the systems that are architected rather than built. The destination those projections point at is an AI CRO, said as a destination rather than as today's capability.

A note on claims

What this website does not say.

We do not publish customer names, deployment counts, funding, revenue, partnerships, certifications, or regulatory status, because none of that has been established in a form we are prepared to stand behind.

What we can show is working technology: a FlashEDC internal CRO tool with strong engine fidelity, and a FlashAnalysis platform covered by approximately 2,500 passing tests with policy-driven provenance governance.

Anything beyond that, we would rather demonstrate in a conversation than assert on a page.

Next step

Start a conversation with the team.

Tell us what you need to evaluate, and we will give you the working technology rather than the narrative.