Lyzerslab

Case study · Speaknix

The platform behind a text-to-speech product, not just the voice model itself

Speaknix's actual product is the natural-sounding voice. Our job was everything around it — the dashboard, the API, the account/billing layer, and the infrastructure that turns a voice model into something a creator can actually generate audio from in seconds and rely on.

Role
Lead full-stack development
Timeline
6 months
Team
4 developers, 1 designer, 1 PM
Speaknix — text-to-speech product dashboard

The challenge

A good voice model is table stakes; a product a creator will pay for needs the parts around it to be just as solid. Before this build, generating usable audio meant stitching together a model, no real dashboard, no API a third party could integrate against, and no usage metering to support a subscription business. Enterprises and educational platforms wanting to convert existing text libraries into audio had no self-serve way to do it at any real volume.

The solution

We built the product layer around the voice engine: a generation dashboard for creators, a documented API for developers who want text-to-speech inside their own apps, and the account, usage-metering and billing plumbing a real SaaS needs underneath both. Inference requests are queued and rate-limited per plan tier rather than run ad hoc, so a large batch job from one account can't degrade response time for everyone else. We treated turnaround time as a product feature from day one — the dashboard shows generation progress in real time instead of a blank spinner, which matters more to a working creator than a marginal gain in voice fidelity.

Key features

  • A generation dashboard where a creator pastes text and gets back playable audio, with real-time progress instead of a blank wait.
  • A documented API and SDK so a third-party app can call Speaknix's voice engine directly, not just use the web dashboard.
  • Per-plan rate limiting and request queuing, so one account's large batch job doesn't slow down generation for everyone else.
  • SSML support, so a creator can control pacing, emphasis and pronunciation rather than accepting the model's single default reading.
  • Usage metering tied to billing, so the pricing plans are enforced by the system, not tracked by hand.

Tech & tools

Next.jsPythonFastAPIAWS LambdaPostgreSQL

The process

01

Discovery

Mapped what a creator actually needs beyond "a voice": turnaround visibility, a way to fix a mispronounced word without regenerating the whole file, and a bill that matches what they used.

02

API & platform design

Designed the API contract and rate-limit tiers before writing the dashboard, so the product and the third-party integration path were built on the same foundation instead of two separate systems.

03

Build

Built the generation queue, the dashboard, and the billing/usage-metering layer as one integrated system rather than a model demo with a login screen bolted on.

04

Load testing

Tested the queue and rate limits under concurrent load from multiple accounts, since the actual failure mode for a text-to-speech product is one large customer starving everyone else of throughput, not the model itself being slow.

Key results

  • A creator generates audio from a dashboard with visible progress, not a black-box wait — the turnaround experience was designed as a first-class feature, not left to the model's raw inference speed.
  • The documented API lets a third-party developer integrate Speaknix's voice engine directly into their own product, instead of the web dashboard being the only way in.
  • Per-plan rate limiting and request queuing mean one account's large job doesn't degrade response time for every other account on the platform.
  • Usage metering is wired directly into billing, so the pricing tiers are enforced automatically instead of reconciled by hand after the fact.

Target audience

Content creators, educational institutions, and accessibility-focused enterprises converting text libraries into audio.

Future scope

Voice cloning for personalized branding and expanded language coverage are scoped as the next phase, building on the queueing and billing infrastructure already in place.