An analytics platform that writes its own R

Problem

Data scientists at a Fortune 500 pharma client were spending their time writing R, not interpreting results. Every question about a compound or study meant locating the right data, standing up an environment, writing analysis code from scratch, generating charts, and assembling findings by hand. Study data was sensitive and access-controlled, so the environment couldn’t simply be opened up. The bottleneck wasn’t analytical skill — it was the distance between having a question and having an answer.

Approach

Owned this as the product: client conversations, what we’d build, and the decisions in between. Led a four-person team — a UI/UX designer and two AI and backend engineers built it. Before anything shipped, interviews with the data scientists themselves found where the time was actually going, and that set the roadmap.

A data scientist opens a study and asks a question in plain English. For a full report, the platform proposes a step-by-step analysis plan and waits for approval. For a single insight, it skips planning and prepares one query. Either way it spins up a compute session reserved for that user, loads only the study data that user is cleared to see, generates and runs R for each step, produces charts, and saves each step’s output before assembling a downloadable report.

The decision worth defending hardest: generated R executes without an approval click. Reviewing every generated snippet would have added friction to every question and made the tool slower than writing the code yourself. Instead we gave users an edit button — the script is always visible and always editable mid-run — and put the review gate on the plan, where a mistake is cheap to catch, rather than on every line of code, where it isn’t.

Outcome

The MVP grew into a $2M+ firm engagement — largely because the client kept expanding scope during the MVP itself, which is the clearest signal a product is landing. What shipped covered an integrated R IDE, plain-English-to-R analysis, automated reporting, compound and study segmentation, and role-based access. Data scientists moved from writing analysis code to reviewing analysis plans.

Technical detail

Data & compute

Study data was organized as a directory structure on S3 at the compound and study level, pulled on demand for a run rather than held in a persistent warehouse. Compute ran on EC2, with sessions spun up in parallel so each user had a dedicated environment and concurrent runs couldn’t collide.

Access control

Access control was enforced at load time, not just in the interface. A user’s session only ever received the studies they were cleared for, so no amount of prompting could surface data they weren’t entitled to. That property mattered more than any single feature: in a regulated environment, a plain-English interface over sensitive study data is only viable if the isolation holds underneath it.

Run modes

The platform supported two run modes with different economics. A full analytical run generated a plan, showed it to the user for confirmation, then produced R code per step with each step’s output persisted to S3 — so a long analysis stayed inspectable and resumable rather than becoming a black box. A single insight run skipped planning entirely for one-off questions. Chart generation and guardrails were built into both.

Direct access & history

Users could also drop into the R IDE directly and query the connected databases themselves, and historical chats were browsable, so prior analyses stayed reusable rather than being re-derived.