DEV Community

Jorge C Lucero
Jorge C Lucero

Posted on

How I Built a Browser-Based Clinical Voice Analysis Platform with Python and Next.js

Voice disorders affect roughly one in three professionals who rely on their voice for work — teachers, lawyers, call center agents, singers. When these patients visit a speech-language pathologist (SLP), the clinician often needs to measure acoustic properties of the voice: how stable is the pitch? How noisy is the signal? How much does the amplitude fluctuate cycle to cycle?

The gold standard tool for this is Praat, a free desktop application that has been the workhorse of phonetics research for decades. Praat is powerful, but it was designed for researchers, not clinicians. Calculating a composite clinical index like AVQI (Acoustic Voice Quality Index) requires downloading specialized scripts, configuring parameters, and manually combining results from two different speech samples. Most clinicians don't have time for that — and surveys consistently show that fewer than half routinely collect acoustic measures during voice evaluations, even though clinical guidelines recommend it.

Commercial alternatives exist, but they cost $1,000–$5,000 and still run only on desktop.

I spent 30 years researching voice production — vocal fold dynamics, mathematical modeling of phonation, physics-based synthesis of disordered voices. When I looked at how clinicians actually use (or don't use) acoustic analysis in practice, the gap between research and clinical reality was striking. So I built PhonaLab: a free, browser-based platform that implements validated clinical voice indices and runs entirely in the cloud.

This is the story of the key challenges, the design decisions that shaped the platform, and what I learned along the way.


The Architecture (High Level)

PhonaLab is a two-service system: a Next.js frontend and a Python/FastAPI backend that handles all signal processing.

Browser (Next.js / React / TypeScript)
    │
    │  audio file or mic recording
    │
    ▼
FastAPI Backend (Python)
    │
    ├── Signal processing engine
    ├── Clinical index computation
    │
    ▼
JSON response → Browser renders results
Enter fullscreen mode Exit fullscreen mode

The frontend handles UI, internationalization (English, Portuguese, Spanish), and session management. The backend receives audio, extracts acoustic parameters, and returns numerical results. That's it — clean separation.

The entire platform runs on managed hosting services at a cost that would surprise most people. No GPU, no Kubernetes, no microservice orchestra. Just two services doing their jobs.


The Hardest Problem: Version Fidelity

The most consequential technical challenge in clinical voice analysis isn't the algorithm — it's making sure your implementation produces exactly the right numbers.

Clinical voice indices like AVQI and ABI were validated using specific software environments. The regression formulas that produce the final index scores were derived from acoustic parameters extracted under particular conditions. If your processing pipeline introduces even small numerical differences in intermediate parameters, those differences propagate through the regression formula.

I discovered this the hard way during validation. Most parameters showed near-perfect agreement with the reference software. But one composite index showed a systematic offset — not because my implementation was wrong, but because of subtle numerical differences between software versions in how an intermediate parameter was computed.

In most web applications, a small difference in an intermediate calculation is irrelevant. In clinical voice analysis, it can shift a patient across a diagnostic threshold.

The lesson: in health applications, version pinning isn't just good practice — it's a clinical requirement. I pin every signal processing dependency and validate after any update. The specific versions and the rationale for choosing them are documented in our validation study.


Stateless Audio Processing: Privacy by Architecture

One design decision started as a constraint and became a competitive advantage: PhonaLab never stores audio files.

The pipeline is simple: audio goes in, numbers come out, the audio buffer is discarded. No audio is written to disk, no recordings are logged, no voice samples accumulate on a server.

This means:

  • No Protected Health Information (PHI) in audio form on the server
  • No data breach vector for voice recordings
  • Simplified compliance posture — there's no sensitive data at rest to protect
  • The backend is truly stateless and horizontally scalable

The tradeoff is that users can't retrieve previously uploaded audio from the platform. But clinicians keep their own recordings — they just need the analysis results, which are stored as numerical values tied to their sessions.

I've come to believe this is the right architecture for any clinical tool where the raw data is sensitive but the derived results are what matter. Don't store what you don't need.


What PhonaLab Measures

The platform offers a suite of analysis tools covering the main clinical use cases in voice assessment:

  • Core acoustic parameters — Fundamental frequency, perturbation measures (jitter, shimmer), harmonics-to-noise ratio, and cepstral peak prominence (CPPS), with comparison against published normative ranges.
  • Multiparametric clinical indices — Including AVQI and ABI, which combine multiple parameters from sustained vowel and connected speech into single clinically interpretable scores. Before PhonaLab, calculating these required running Praat scripts manually.
  • Spectral and cepstral analysis — Long-term average spectrum, spectral ratios, and composite spectral indices.
  • Visualization tools — Pitch contours with formant tracking (particularly useful for gender-affirming voice therapy), interactive spectrograms, and waveform displays.

Each tool includes rule-based interpretation that flags values outside normative ranges — giving clinicians immediate context without requiring them to memorize threshold values for a dozen parameters.


The Validation Problem

Building a web tool that computes acoustic parameters is not hard. Building one that clinicians can trust is a different problem entirely.

Clinical voice analysis isn't like rendering a chart. If your perturbation calculation is off, a patient might be incorrectly classified as disordered — or incorrectly classified as normal. Clinicians make treatment decisions based on these numbers.

So I did what any researcher would do: I ran a formal validation study.

I used the Perceptual Voice Qualities Database (PVQD) — a publicly available collection of 296 voice recordings with expert perceptual ratings. I processed all recordings through both PhonaLab and the desktop reference software, then assessed:

  1. Algorithm agreement: Do the two platforms produce the same values for the same audio?
  2. Concurrent validity: Do PhonaLab's outputs correlate with expert perceptual ratings at levels consistent with published validation studies?

The results confirmed strong agreement and consistent validity. The manuscript is under peer review at the Journal of Voice.

This validation step turned out to be the single most important investment for adoption. "Validated against Praat" and "peer-reviewed" are the phrases that convince clinicians to trust a new tool. One international researcher chose PhonaLab over other free alternatives specifically because the platform is citable in academic work.


Challenges Along the Way

Audio format chaos

Clinicians record in everything — WAV, MP3, M4A, sometimes OGG. The signal processing engine expects a specific format. The backend handles conversion and sample rate standardization transparently, but edge cases abound: variable bit-rate files, telephone-quality 8kHz recordings, stereo files where one channel is silent. Robust audio ingestion is unglamorous but essential.

Browser microphone recording

Adding in-browser recording via the MediaRecorder API opened the platform to clinicians who don't have separate recording software. The UI uses a two-tab pattern (Upload File / Record Voice) across all tools. This single feature significantly reduced friction for new users.

Internationalization from day one

Supporting three languages (English, Portuguese, Spanish) was an early investment that paid off. International markets — particularly India, Spain, France, and Brazil — showed stronger engagement than expected. Building i18n into the architecture from the start is far easier than retrofitting it.

The cold start problem

Managed hosting platforms can introduce latency on the first request after idle periods. For a tool where clinicians expect near-instant results, even 2–3 extra seconds feels broken. Solving this without overprovisioning required some creative workarounds, but it's a real consideration for any latency-sensitive service on managed infrastructure.


Growth: Zero Budget, Organic Only

PhonaLab launched in October 2025. Within six months:

  • 1,000+ registered users across 60+ countries
  • 4,700+ analyses completed
  • 100+ power users (5+ sessions each)

No paid advertising. No Product Hunt launch. No venture funding. What worked:

Educational content. I published a series of articles explaining voice science concepts — what CPP means, why multiparametric indices outperform single measures, how to read spectrograms. These rank well for long-tail clinical queries and drive organic discovery by the exact audience that needs the tool.

Being the only free web-based option for validated clinical indices. For measures like AVQI and ABI, there simply wasn't a free, browser-based tool that implemented them with a proper validation pipeline. When clinicians search for alternatives to expensive desktop software, PhonaLab appears.

Academic credibility. A Journal of Voice submission, conference presentations, and decades of published voice research give clinicians confidence that the science is sound. In healthcare, trust is the product.


Key Takeaways for Developers Building Health/Science Tools

1. Pin your dependencies like your users' health depends on it — because it does. In clinical applications, a minor library update can shift results across diagnostic thresholds. Document your versions. Validate after every update.

2. Stateless processing is a superpower. Not storing sensitive data simplifies your architecture, your compliance story, and your security posture. If you only need derived results, don't store the raw input.

3. Validation is your moat. Any developer can build an analysis tool. A peer-reviewed validation study is what separates a research-grade platform from a weekend project. If you're building for clinicians, invest in validation early.

4. Content is the best marketing for niche tools. Educational content that genuinely helps your target audience is the most effective — and cheapest — way to reach them. Write about the domain, not the product.

5. The "boring" decisions are the important ones. Choosing the right signal processing version, handling audio format edge cases, designing a stateless pipeline — none of this is glamorous. All of it is what makes the tool trustworthy.


Try PhonaLab: www.phonalab.com — Acoustic voice analysis tools for clinicians, researchers, and voice professionals. Validated against Praat. No installation required.

If you're building tools at the intersection of signal processing and healthcare, I'd love to hear about your experience — drop a comment or connect with me.

Top comments (0)