← All work PRIVATE EQUITY · INTERNAL PLATFORMS · SOLE DESIGNER

Quantum Capital Group

Sole designer at a private equity firm with no commercial products - everything built here is internal, for the people who work at the firm. This is the story of LP Nexus, the platform I took from one unused screen to daily use in four months, plus the rest of the work that ran alongside it.

Role
Sole Product & Visual Designer
Focus
LP Nexus, Well & Field, design system
Started
Oct 2025
Scope
Research, IA, hi-fi design, front-end, visual
1 → 5Screens to full platform
10 wksBrief to final design
~25Daily users

The problem

01

Quantum Capital Group managed its limited partner relationships through DealCloud - a CRM configured for deal and pipeline tracking. It did that job well. It was never built for the ongoing work of investor relations.

So the work that defines an LP relationship had no home. Call notes, due diligence questionnaires, meeting history, tearsheets, inbound requests - each lived in a different place, or in no particular place at all. An IR associate preparing for a conversation with an investor had to assemble context from a CRM that wasn't designed to hold it, plus whatever had been saved elsewhere.

LP Nexus already existed, technically. It was a single Call Notes screen - closer to a shared calendar than a product, and barely used. The brief was to turn that into the platform the team actually needed.

Starting cold

02

I joined Quantum in October 2025 and was handed this project within weeks - my first substantial piece of work at the firm, in a domain I was still learning. Private equity investor relations has its own vocabulary and its own workflows, and I had neither yet.

That shaped how I worked. With no accumulated knowledge to draw on, I leaned on the people who had it: the IR team who would use the product, and the engineers who understood what the existing systems could and couldn't do. Most of the first few weeks was learning what the work actually involved before proposing what the software should do.

It also created the failure mode described below - the places where I filled a gap in my understanding with an assumption, and found out later that the assumption was wrong.

Key decisions

03
Decision 01

Structuring five functions with no precedent to borrow from

The tension: Call Notes, LP Requests, Due Diligence, Tearsheets and Meeting Notes all had to live in one platform. Nothing in the firm's existing tooling suggested how they should relate to each other - and as the newest person on the team, I had the least context for deciding.

The familiar option was to mirror DealCloud. Everyone knew it, and borrowing its structure would have made the new platform feel recognisable on day one. I went the other way. DealCloud organises around deals and pipeline; LP Nexus needed to organise around the relationship. Inheriting a structure built for a different job was how the team ended up with the problem in the first place.

So I structured the platform around the shape of the IR team's work rather than the shape of the tool it was replacing, and made each function reachable without leaving the platform.

Decision 02

Designing the DDQ flow before the process was documented

The tension: The due diligence questionnaire lifecycle existed in practice but had never been written down. I could wait for it to be documented, or design against my best reconstruction and correct later.

I designed against a reconstruction - and got it wrong. My version included stages that weren't part of the real publishing process. The mismatch surfaced when I walked the flow past the primary stakeholder, who recognised immediately that it didn't match how DDQs actually move.

Working with the dev team, I rebuilt the stage structure around the real lifecycle. That correction is what produced the stage-status badges - In Progress, Completed, and the rest. They only made sense once the underlying stages were right; against my invented flow they would have been labels on a process nobody followed.

The lesson I'd carry forward: when a process is undocumented, that absence is itself worth surfacing early. I treated it as a gap to design around when it was really a question to ask.

Outcome

04

High-fidelity design was complete by the end of December. Development began in January, and a working build was live by the end of the month. The IR and fundraising team - around 25 people - has been working out of it since.

I don't have hard numbers, and I'd rather say so than reach for them. What I can report is adoption: the team now does its LP relationship work in one platform instead of splitting it between a CRM that wasn't built for it and a set of manual processes that lived outside any system.

Also at Quantum

05

LP Nexus ran alongside the rest of the role. As the only designer at the firm, the work spans product, systems and visual design - often in the same week.

Product · Oil & gas

Well & Field Data Operations

An operations platform onboarding over six million data points. I designed it end to end and contributed HTML, CSS and JavaScript to get version one shipped.

6M+ data points
Design systems

Component library & tokens

Quantum had no functioning design system. I rebuilt what existed into roughly 23 token-based components and resolved accessibility failures across both light and dark themes. This is work I'm solely driving on an ongoing basis.

~23 components
Visual design

Brand & collateral

The role is product and visual design in one. Alongside platform work I handle graphics and internal collateral - the visual layer the firm's products and communications sit inside.

Ongoing