Vega: Replacing a third-party dependency with an AI-native product master
Overview
- My role
- Senior Product Designer
- Industry
- Fintech · Private markets
- Scope
- Product master · Fund data platform
Vega runs fund operations for GP clients but can't manage core fund data in-house: the fund → vehicle → share class hierarchy behind offering pages, subscriptions and reporting. For its first client, Apollo, Vega integrated with Daphne via API and relied on Daphne's product master. This case study covers why that dependency now limits growth, and the plan to replace it with a native product master.
Problem
Every GP Vega onboards needs static fund data from somewhere, and today that is Daphne. So Vega can't bring on a new GP without bringing Daphne into the relationship: a third party supplying a capability at the centre of the platform.
That causes two compounding problems. It caps growth, because onboarding speed depends on a partner Vega doesn't control. And it leaves a core part of the product off Vega's roadmap, so reliability, self-service and the data model can't improve on Vega's timeline.
Scope note: the fix is not to compete with Daphne or productize this as a standalone offering with external APIs. It's to remove the dependency for Vega's own onboarding pipeline.
Solution
Vega is building an AI-native product master, designed around a simple pipeline: ingest → review → publish.
Ingestion. GPs bring in fund data as-is (documents, spreadsheets, existing records) rather than filling out forms field by field. The system parses the fund → vehicle → share class hierarchy directly from what's submitted.
Review parsed fields. GPs check and correct the parsed output before anything goes live: self-service without sacrificing accuracy. This checkpoint is what makes AI ingestion trustworthy rather than a black box.
Publish fund. Once reviewed, fund data is published and immediately usable by downstream services (offering pages, subscriptions, reporting) with no manual re-entry step.
This pipeline is built around three additional principles:
Data parity, not data replication.The new system covers every mandatory field downstream services take from Daphne today, so nothing degrades in the switch. The goal, though, is a best-in-class data model built for Vega, not a 1:1 copy of Daphne's schema.
A genuine alternative to Daphne, not a workaround. Once live, Vega should be able to onboard a new GP end-to-end (static product data included) without any Daphne integration at all.
Faster onboarding by design.The Daphne-dependent workflow is the baseline to beat: ingest → review → publish is built to cut the time and effort of bringing a new GP's fund data online.
Results
The product master isn't live yet, so these are targets, not results:
Under 1 day of Vega operational effort to onboard the next GP after Apollo, with all product data on the Vega product master.
≥90% positive feedback from pilot GP users on reliability and ease of use, tracked over the first year through quarterly interviews.
5+ additional GPs supported by the Fund Management service(s) by end of 2026, scaling horizontally and elastically with load.
This prototype was 100% built with Claude Code and a set of custom skills we wrote. The skills were authored by our lead design engineer George Drury.
Open to new projects and ideas
Building something in AI, finance or complex workflows? I'd love to hear about it.
Send email