Months to weeks: the pipeline builder that made ML work reusable

Who I Am

I was the lead product and motion designer on Stradigi AI’s internal pipeline builder, the tool that changed how our ML agency delivered client work. Before this, every project started from zero: the code from the last client’s model lived in that client’s folder and nowhere else, and the next data scientist rebuilt what the last one had already solved.

I’m drawn to problems where the fix isn’t a new client-facing feature but an internal system nobody’s gotten around to building: the unglamorous infrastructure work that changes what a team is capable of shipping. My job was to take the way our best data scientists already worked and turn it into something reusable, without asking them to change how they thought through a model.

The goal was never to ship a tool. It was to stop starting from scratch.

Challenge

The Real Cost of Rebuilding

Stradigi AI was an ML agency: a dedicated team building custom AI solutions for outside clients, one contract at a time.

Every project was different, but underneath, most of them weren’t. The same kinds of models, the same kinds of data problems, solved again from scratch each time, because nothing from the last project was built to be reused.

The cost showed up on the data scientists’ own screens. A typical project meant 30 to 40 open Jupyter notebook tabs, each a slightly different version of the same model, with no shared naming convention and no record of which approaches had already been tried. When a client came back with changes, the team was often starting over rather than building forward.

That wasn’t a talent problem. Our data scientists were good at their jobs. It was a structural one: nothing about how the team worked made yesterday’s solved problem available to tomorrow’s project.

This was not a hiring problem.
It was a reuse problem.

Solution

Research & Discovery

We started by sitting with the data science team and watching them work rather than asking them to describe it. Three things stood out immediately: every experiment lived in its own notebook tab, there was no way to compare experiments side by side, and there was no record of what had already been tried. When a client asked for changes, that missing history meant starting over.

The goal became clear: give experiments a structure. Make them visual, labeled, and reusable, without changing how a data scientist actually thinks through a model.

The Solution: A Visual Pipeline Builder

Working closely with the data science and development teams, we evaluated open-source frameworks we could customize rather than building the underlying engine from scratch, and settled on a node-based framework built for exactly this kind of visual workflow.

The core idea: house snippets of code in reusable nodes we called blocks. Data scientists could connect blocks together the same way they already thought through a notebook, but each block was now a saved, shareable unit instead of a line buried in a one-off script. We built this out in stages: conceiving the block concept, shaping it through wireframes and small proof-of-concept builds, running usability tests with the data science team, and iterating based directly on their feedback rather than our own assumptions about how they’d use it.

One of the first features we shipped addressed the messiest part of any experiment: importing and cleaning data that rarely arrived clean or consistently structured. We built a way to visualize the incoming data, a table view for inspecting it directly, and a set of cleaning tools data scientists could apply without leaving the pipeline.

The blocks themselves created a new problem once people started using them. Data scientists enjoyed connecting blocks together (it felt like snapping Lego pieces into place), but got frustrated debugging pipelines when blocks were connected incorrectly. That friction led to a real design decision: we built logic directly into the blocks and added visual cues showing which blocks could actually connect to which, so a bad connection failed loudly instead of silently. That single change turned a fun-but-fragile interaction into one people trusted enough to build real projects on.

How it shipped

After six months of work, we had a genuinely useful, if not fully polished, internal tool: the kind of tradeoff every internal product makes against a client-services team’s budget and headcount. We built a process around it: when a client raised a problem, we could check the existing codebase for anything similar, reuse it directly if we’d solved it before, and only write new code when the problem was genuinely novel. That new code became a new block, so the library kept compounding with every project. Alongside the pipeline builder itself, we shipped a companion dashboard so the team could see experiment results and model performance without leaving the workflow.

Results

From Rebuilding to Reusing

Client project timelines dropped from months to weeks. Work that used to start from a blank notebook now started from a library of blocks the team had already validated, and we were able to import an open-source code library that further cut down how much custom code any given project needed.

If I built this again, I’d validate every block with the data science team before shipping it. The features that stuck were the ones we tested directly with them; the ones we skipped that step on saw the lowest adoption, no matter how useful they looked on paper.