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, leaving business development with little capacity to pursue them.Every API came with its own integration requirements.
Differences in authentication, input formats, and delivery created repeated work for both customers and internal teams.Product decisions were scattered across teams.
Without common standards, each new offering required teams to resolve many of the same questions again.
These were not separate operational issues. Gaudio Lab had technologies customers wanted, but lacked a consistent way to package and deliver them as products.
Product Strategy
Start with APIs, but design beyond the first release
The goal was to make the path from product discovery to first API call and payment possible without sales involvement.
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 be shared, 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 what engineering and the business could support. I defined a common structure for onboarding, authentication, usage, billing, and product information that could support additional models over time.
Existing enterprise contracts also constrained pricing. Rather than replacing those arrangements, we needed a self-service option that could operate alongside them.
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 shaped 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 flows, organized around four core areas designed to accommodate future products.
Information architecture I defined
Screen-level product requirements
Prototyping
Prototyping to make decisions tangible
Some decisions were difficult to settle through specifications alone, particularly when stakeholders had different levels of familiarity with developer tools.
I used AI coding agents to build interactive prototypes so teams could compare options through actual use rather than abstract descriptions.
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 set up 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 path to documentation, an API key, and the first request consistent.
02. Comparing ways to explore usage
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 efforts were moving 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 turn 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 4 months of launch
~$50K
First enterprise contract closed within a month
2×
Paying enterprise
customers within 3 months
Customers gained a direct path to explore, integrate, and pay for audio AI products. Internally, teams could introduce additional APIs through a common product structure rather than rebuilding each integration from scratch.
The platform also expanded the company's commercial reach beyond its existing Korea-focused customer base.
Reflection
The hardest decisions were about where complexity belonged
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 decisions that were already fixed, particularly enterprise pricing arrangements. Not every inconsistency could be removed in the first release.
This project taught me to distinguish complexity that belongs in the product from complexity the user should never have to manage. Making that distinction required understanding the technology, the business, and the customer's work well enough to decide where the boundaries should be.
Thanks for coming by.
© 2026 Hailey Moon