Adekunle Omorotimi

Voice AI platform · Sumeru Tech

Voice Labs

Speech-to-text, text-to-speech and telephony behind one workspace-scoped API, with a dashboard and a TypeScript client. It is the V2 of Voice Panel, the internal voice layer that serves many of Sumeru Tech's products. I built its text-to-speech, voice catalogue and translation capabilities and its CI.

role
Full-stack engineer, one of three; mostly API and platform work
organisation
Sumeru Tech
period
2025 – present
  • 17

    pull requests merged across text-to-speech, voices, translation and CI (3 more open)

    source: Repository history, 10 Nov 2026

The problem

Several products need voice (tutoring, a voice CRM, an AI concierge). Rebuilding speech, voices, translation, metering and security in each would multiply the work and the risk. Voice Panel (V1) proved the need as a shared internal tool; V2, Voice Labs, rebuilds it as a proper platform: one API, one SDK, one dashboard, with every workspace's data kept apart.

What I built

The platform exposes speech-to-text, text-to-speech and telephony through one workspace-scoped API (a Bun and Hono server under /v1), a Next.js dashboard and a TypeScript client SDK. The repository is private; I am one of three engineers on it.

I built the text-to-speech capability end to end: the contract and schema first, then synthesis with metering and seekable playback (audio is answered in ranges of at most 1 MiB), and then workspace defaults and pronunciation rules.

I built the voice catalogue: syncing voices by engine, curated metadata (gender, age range, accent), filters, and ranked suggestions that put the same language and region first. A voice owned by another workspace is simply not found.

I wrote the contract and first implementation of the translation capability, billed per character, and the pull-request pipeline that runs lint, types, tests and builds on every change.

A speech requestHow a text-to-speech call moves through the platform.
external

SDK call. A product calls the TypeScript client with its workspace key.

Diagrams are simplified from the work described above. Node colours: model, code, external service, person or result.

Screens

  • Voice Panel home overview with cards for Text to Speech, Speech to Text, Voice Library, Create Agent and Libraries and SDK.
    Voice Panel V1: homeVoice Panel (V1), from a demo account: the overview, with entry points to Text to Speech, Speech to Text, the Voice Library, agents and the SDK. The sidebar groups core services, development, insights, support and settings.
  • Voice library showing 22 voices with free and premium badges, locale and gender, a preview button and filters.
    Voice Panel V1: voice libraryThe voice library: 22 curated voices across languages and accents (Telugu, Polish, French, Dutch, Thai and more), with free and premium tiers, filters by gender and locale, search and a preview for each voice.
  • Text to speech workspace with a voice list, a text editor, a generate button and a history panel.
    Voice Panel V1: text to speechText to speech: a voice picker with locale metadata, an editor that also accepts uploaded files (PDF, Word, images, audio, text), a generate action and a history of syntheses.
  • Libraries and SDK documentation: a React voice UI component with install instructions and key properties, and a Node.js SDK section list.
    Voice Panel V1: libraries and SDKLibraries and SDK: documentation for a React voice interface component (install, basic configuration, theming, a hook) and a Node.js SDK covering authentication, text-to-speech, speech-to-text, credits and analytics, and RAG and agents, with examples and a reference section.

Engineering decisions

  1. 01

    Contract first

    Each capability starts as a small pull request holding its schema, types, route stubs and a test skeleton. Nothing else begins until that is approved, so reviewers agree on the shape before the code exists.

  2. 02

    Neutral capability names

    No provider or vendor name appears in any public response, error, route or SDK type, and a test scans the SDK for vendor names. Providers can change without breaking customers.

  3. 03

    Workspace-scoped, cursor-paginated, server-filtered

    List endpoints are scoped to a workspace and paginated by cursor from their first version, with search and filters on the server. Timestamps are stored to the millisecond so paging never skips a row.

  4. 04

    Controls come from capability descriptors

    Ranges and settings are read from what an engine can actually do, not hard-coded, so the dashboard never offers a control the pipeline would ignore.

Stack

Server
  • Bun
  • Hono
  • TypeScript
Data
  • PostgreSQL
  • Drizzle
  • Redis
Dashboard and client
  • Next.js
  • TypeScript SDK
Realtime and delivery
  • LiveKit
  • Docker Compose
  • GitHub Actions
  • Infisical

next case study

SchoolExl / TrainExl
Discuss this work