InfraBrix

2023–2026

What if data scientists could launch their tools in one click?

The dashboard: services to launch at the top, running instances below, each in its project or none.

InfraBrix began as the CTO’s idea, which we turned into my M2 diploma project in 2021–22: a store for open-source infrastructure software, with a workspace you reached after buying. I joined the company in September 2023 as its only designer.

By 2025, as AI reached sensitive data, the conversation had moved to security and sovereignty, and a store was answering the wrong question. The CTO set the product on-premise, for data scientists in organisations handling sensitive data. My part was to put the workspace first. The product was where they would work, not where they would buy.

InfraBrix began as the CTO’s idea, which we turned into my M2 diploma project in 2021–22: a store for open-source infrastructure software, with a workspace you reached after buying. I joined the company in September 2023 as its only designer.

By 2025, as AI reached sensitive data, the conversation had moved to security and sovereignty, and a store was answering the wrong question. The CTO set the product on-premise, for data scientists in organisations handling sensitive data. My part was to put the workspace first. The product was where they would work, not where they would buy.

Role

Sole designer

Project lead

Team

Daily pair with the CTO

PM, DevOps, lead data scientist (intermittent)

Outcome

Coded interactive prototype

v0 backlog for the MVP

Handed over before the build

Role

Sole designer

Project lead

Team

Daily pair with the CTO

PM, DevOps, lead data scientist (intermittent)

Outcome

Coded interactive prototype

v0 backlog for the MVP

Handed over before the build

Problem area

One workflow, five tools set up one by one

To see what a data scientist actually goes through, we rebuilt a real workflow in-house, with our own specialists standing in: a model of how heatwaves affect hospital admissions, chosen in a workshop I prepared and framed. Our junior DevOps engineer assembled its pipeline, then walked me through every point where it had been harder than it should have been.

The workflow before the platform

Diagram of the Heatwave pipeline: five stages from extraction to visualisation, each run by its own tool, with CloudBeaver verifying every stage. NiFi, Superset and CloudBeaver are tagged ‘by hand’, where the same storage setting was configured three times; KNIME is tagged ‘outside containers’.

Opportunity 1

KNIME ran outside the containers, on an older Python.

Launch every tool in one step, at a version the platform supports.

Opportunity 2

One storage setting was configured by hand for NiFi, Superset and CloudBeaver.

Connect instances once, inside a project, so no setting is configured twice.

Design decision 01 · Launch

Launch in one click, configure later

The earlier launch form asked for everything up front, including settings such as persistence. Someone launching a tool rarely knows those answers yet, and shouldn’t have to. The new form keeps three fields, a name, a version and a compute size, and pre-fills all of them, with the rate shown before launch. Accepting the defaults makes a launch one click.

The settings didn’t disappear. They moved to the instance page, and that split follows two people. Léa, a junior data scientist, needs to get started. Karim, a senior ML engineer, needs to change what the platform decided. I designed each default, and the CTO confirmed it could be built.

The launch form in 2026: three pre-filled fields (name, version, compute size) and the rate shown before launch. Accepting the defaults launches in one click.

The 2026 prototype, then the May 2025 wireframe: the settings moved to the instance page.

Design decision 02 · Instances

Show the wait, don’t hide it

Once launched, an instance takes 30 to 90 seconds to be ready, by the CTO’s estimate. In that time the interface checks the backend every 5 to 10 seconds, and the badge changes only when the backend confirms the instance is ready.

The instance table doesn’t show more than that. Its status badge has four values, Starting, Operational, Stopped and Error, so a long list stays easy to scan. The detail goes where the person who launched is looking: a notification follows the launch until the instance is ready, then offers to open it or add it to a project.

Diagram of an instance launch in two rows. Top row, what the backend does: Launch, 202 Accepted, Polling every 5–10 seconds, Badge update, Connected. Bottom row, what the instance table shows: Starting under the first three steps, Operational under the last two. Stopped and Error are listed as the other two status values.

Four statuses in the table; behind Starting, the steps the backend reports.

Design decision 03 · Projects

Manage a project, not a list of tools

In the Heatwave pipeline, one storage setting was configured by hand for three tools. In a project, that set-up happens once, and the project carries it. Instances added to it are pre-wired: NiFi writes into the project’s PostgreSQL, and KNIME finds its connection already filled in. Files work the same way. Upload a file once, and every tool in the project can read it.

A project doesn’t remove the data work. It removes the set-up around it.

The Hospital Forecasting project page in the prototype, listing its three instances, including hospital-db-postgres and hospital-forecast-jupyter, already connected, with the project’s members.

Hospital Forecasting: three instances, already connected.

Design system

A service has no status, an instance has no members

The system is built on Simple Design System by Figma (CC BY 4.0). On top of it, I built one component for each noun in the vocabulary, and each component shows only what its noun owns. The service card sits in the catalogue. It says what the software does and how to launch it, but never shows a status, because a service doesn’t run. The instance row is a running copy, so it shows its status, its cost and its project, if it has one. The project card holds what no instance has: its members, and the instances it connects.

Diagram of three components, one under another. A PostgreSQL 15 service card leads by ‘launch’ to an instance row, hospital-db-postgres. ‘Add to project’ leads to the same row, now showing the project Hospital Forecasting. ‘Belongs to’ leads to the Hospital Forecasting project card, with its connected instances and members.

Service → Instance → Project, as components: each shows only what its noun owns.

Retrospective

Where it stood

The launch path in the coded prototype.

The prototype was built in Cursor from my designs: a front end the team could click through and decide on. I handed it over with a v0 backlog for the MVP, where connecting it to the backend and testing it with users were the next steps.

Before handing it over, I checked each persona’s journey against it. Along the launch path, two gaps stood out. Quick Start assumes Léa already knows the word Jupyter. And Karim’s instance page shows him why something is slow, but doesn’t let him resize it.

Three habits came out of the project that I’d use again: fix the words before drawing the screens, layer different people’s needs instead of averaging them, and check whole journeys, not only flows.

Last updated: October 2026

Last updated: October 2026

Last updated: October 2026