Audio AI Developer Platform
Key Insights
— From custom AI integrations to a self-service developer platform
Gaudio Lab's audio AI products required custom integrations and hands-on support for each customer. I led the platform from discovery through launch, defining the product strategy, API requirements, and developer experience while coordinating AI, engineering, design, and business teams.
The Problem
Manual sales process
Even small deals required hands-on sales support.
Fragmented APIs
Each API had its own integration requirements.
Fragmented product decisions
Five teams lacked a shared set of product requirements.
What I did
Self-service experience
Designed the user journey from product discovery to the first API call.
API standardization
Standardized authentication, usage tracking, and error handling.
Cross-team alignment
Aligned five teams around a shared product definition.
Business Outcomes
4→12
API products within four months of launch
~$50K
First enterprise contractclosed within one month
2×
Paying enterprise customers within three months
Background
Advanced AI, Delivered One Customer at a Time
Gaudio Lab developed audio technologies ranging from source separation and noise removal to text-to-audio generation and spatial audio. Each was delivered through separate teams and delivery arrangements, often requiring custom work before a customer could begin using it.
As the portfolio grew, this approach became increasingly difficult to scale.
Research
Different Teams, One Underlying Problem
I interviewed 10 stakeholders across the product lifecycle, including customers, business developers, AI researchers, engineers, and the CEO. I traced how technologies moved from the lab to paying customers and identified where the process broke down.
Three recurring issues emerged:
Sales was involved in nearly every step.
Even smaller integrations required manual coordination, limiting the business development team's capacity to pursue additional opportunities.Every API came with its own integration requirements.
Differences in authentication, input formats, and delivery methods forced customers and internal teams to repeat integration work.Product decisions were fragmented across teams.
Without common standards, each new offering required teams to revisit the same product and technical decisions.
These were symptoms of a broader problem: Gaudio Lab had technologies customers wanted, but lacked a scalable way to package and deliver them as products.
Product Strategy
Start with APIs, but Design for Scale
The goal was to enable customers to discover products, make their first API calls, and pay for usage without sales assistance. The challenge was deciding what the first release should include.
I worked with stakeholders to evaluate three questions:
What should we sell?
Which technologies were ready to become standalone products?How should customers access them?
Which capabilities could share a common structure, and which required model-specific treatment?
What should the platform expose?
How much technical and usage information did customers need to work independently?
We chose APIs for the initial release, balancing customer demand with engineering capacity and business priorities. I defined a shared structure for onboarding, authentication, usage tracking, billing, and product information that could accommodate additional models over time.
Existing enterprise contracts also constrained pricing. Rather than replacing those arrangements, we designed the self-service offering to complement existing contracts.
System Design
Standardize the Integration, Not the Underlying Models
The AI models differed in what they accepted, how they processed audio, and what they returned. Treating them as identical would have obscured information developers needed, while treating each as a separate product would have recreated the same integration problems.
I worked with AI researchers and engineers to define shared conventions for API calls, authentication, usage measurement, and error handling while preserving model-specific input and output requirements.
These decisions informed both the technical specifications and the developer experience: what users needed to configure, what the platform could handle, and where differences between models had to remain visible.
I translated this structure into the platform's information architecture, screen-level requirements, and user flows across four core areas, with room to accommodate future products.
Information architecture I defined
Screen-level product requirements
Prototyping
Turn Open Questions into Testable Decisions
Specifications alone were not always enough to resolve disagreements, particularly when stakeholders had different levels of familiarity with developer tools. I used AI coding agents to build interactive prototypes, allowing teams to compare alternatives through hands-on evaluation rather than abstract discussion.
01. Different Entry Points, One Path to the First API Call
The platform needed to support three onboarding scenarios: a manager creating a new project, a manager joining an enterprise project provisioned by Gaudio Lab, and a team member joining by invitation.
Each required different permissions and setup steps. I tailored the entry flows to each role while keeping the core journey to documentation, API key generation, and the first request consistent.
02. Making Usage Data Easier to Explore
Audio AI models had different inputs, outputs, and processing requirements, making a single usage dashboard difficult to design. I grouped the models by input and output type, then prototyped three filter structures and three levels of detail.
We selected separate, visible filters so users could see their options without navigating nested menus. Charts focused on request volume and cost, while processing time and errors remained available in the detailed table.
Explore the dashboard prototypes
Building
Five Workstreams, One Shared Product Definition
Five workstreams progressed in parallel: model benchmarking, API standardization, design system development, documentation, and billing.
Each depended on decisions made elsewhere. I maintained a shared set of product requirements covering what constituted an API product, how calls worked, how usage was measured, and how failures were handled.
I coordinated dependencies across teams and worked with the product designer to translate my wireframes and interaction requirements into the final interface. The designer developed the visual system, while I continued refining the flows, specifications, and implementation details with engineering through launch.
Outcome
A Repeatable Way to Launch and Sell AI Products
4→12
API products within four months of launch
~$50K
First enterprise contract closed within one month
2×
Paying enterprise customers within three months
Customers gained a direct way to explore, integrate, and pay for audio AI products. Internally, teams could introduce additional APIs through a shared product structure rather than rebuilding each integration from scratch.
The platform also helped extend the company's commercial reach beyond its existing Korea-focused customer base.
Reflection
Deciding Where Complexity Belongs
Building a self-service platform did not mean making every AI model behave the same way. Some differences were essential for developers to understand; others could be handled behind a consistent interface.
I also had to work within existing constraints, particularly enterprise pricing arrangements. Not every inconsistency could be resolved in the first release.
This project taught me to distinguish complexity that users need to understand from complexity the product should absorb. Making that distinction required balancing technical realities, business constraints, and the way customers actually worked.
Thanks for coming by.
© 2026 Hailey Moon