← All work

Case 03 · Discovery · In progress · 2026 · 5 min read

Voice capture for Hinglish: testing whether to build

My own difficulty transcribing Hindi-English recordings prompted this study. I am testing whether existing engines are meaningfully better than built-in recognition, and whether that improvement supports a paid product.

Skip to the decisions

Problem

Phone speech-to-text breaks on regional accents and on Hinglish, the Hindi-English mix many Indians speak every day.

What I did

Designed a comparison of four engines on real recordings and Indian-accent speech data, scored on transcription errors, speed and cost, with numeric decision thresholds set before testing.

Status

In progress. No engine winner, validated willingness to pay or build decision yet. The findings will be published here, including a kill if that is what the data says.

Role
Solo: framing, research, model evaluation, business case
Type
Discovery and evaluation study (pre-build)
Status
In progress, October 2026
Skills
User research, AI evaluation, unit economics, build-or-kill judgment

Problem

Built for American English

Phone speech-to-text works well for American English. It breaks for many Indian speakers.

  • Regional accents and dialects produce wrong words and broken sentences.
  • Indians often mix Hindi and English in one sentence (Hinglish). Built-in engines handle this badly.
  • I saw this first-hand: built-in phone recognition struggled with local accents, and transcribing my own long Hindi-English recordings took real effort.

Users

Who feels it, and who would pay

Sell hereIdealAvoidTest hereEASE OF REACH →WILLINGNESS TO PAY →Studentsprimary for testingSales andclient-facing prosField workers, SMBsaccuracy: test with studentswillingness to pay: ask salesPOSITIONS ARE QUALITATIVE, FROM DESK RESEARCH
Two different questions, two different groups. Students are cheap to reach for testing transcript accuracy. They cannot show whether sales teams would pay, so buyer interviews go to sales and client-facing professionals directly.
SegmentUse caseWillingness to pay
Students (primary for testing)Record lectures, get notes and summariesLow to medium; easy to reach
Sales and client-facing professionalsCalls and meetings in mixed languageHigh. Globally, sales teams bring most AI notetaker revenue (Sacra on Otter.ai)
Field workers and SMB ownersVoice notes instead of typingMedium; large but harder to reach

Hypotheses

What the study must prove or kill

  • H1. The gap is in Hinglish and regional accents, not Indian English overall. A general engine can look fine on average and still fail the users who need it most.
  • H2. An India-first engine closes the gap. At least one engine cuts Hinglish word errors by 25% or more against Apple's free baseline.
  • H3. The economics work for one paying segment. A heavy user's monthly audio cost is under 40% of a plan price that segment says it would pay.

Research plan

Two kinds of validation before any build

Real clips20 to 30 lectures,calls, HinglishSvarah setopen Indian-accentspeechSarvamIndia-firstOpenAI minigeneralDeepgram Nova-3Hinglish modeApple built-infree baselineScoredWER by accentWER by language mixspeedcost per hourDecision ruleset before testingBuildPivotKillone numberdrives the call
The technical test as a pipeline. Same clips, four engines, the same scores, and a decision rule written before the first clip is tested.
  1. Buyer interviewsSales and client-facing professionals, the segment most likely to pay: how they capture calls today, where voice fails them, and what they pay for now. Students are interviewed on the same workflow questions, but their answers are not used as evidence of willingness to pay.
  2. Accent test20 to 30 real clips (lectures, client calls, Hindi-English mixes) from speakers across north, south, east and west India, plus open Indian-accent data such as AI4Bharat's Svarah set.
  3. Engines comparedSarvam (built for Indian languages), OpenAI's mini transcription model, Deepgram Nova-3 (Hinglish mode), and Apple's built-in engine as the free baseline.
  4. MetricWord error rate (WER) by accent and by language mix, plus speed and cost per hour.

Decision rule

Set before the first clip is tested

If the data showsThen
The best engine cuts Hinglish WER by 25% or more against Apple's baseline, and its heavy-user cost is under 40% of a plan price the paying segment accepts in interviewsBuild a narrow pilot for that segment
The best engine improves Hinglish WER by less than 25%Pivot: compete on output (summaries, action items) on top of free transcripts
Every engine, including the best, gets more than 1 word in 4 wrong on Hinglish (WER above 25%)Kill for now: at that error rate, correcting the transcript takes longer than typing notes. Revisit when models improve

If the accuracy bar is met but the cost bar is not, the answer is a pivot to capped plans, not a build.

Engines

Engines and list prices

EngineBuilt forCost per hour (list, Oct 2026)WER
SarvamIndian languagesRs 30In testing
OpenAI mini transcribeGeneral, multilingualAbout $0.18 ($0.003 a minute)In testing
Deepgram Nova-3General, with a Hinglish modeAbout $0.46 ($0.0077 a minute)In testing
Apple built-inOn-device baselineFreeIn testing

Decisions and trade-offs

Four calls, and what each one cost

01Test before build

What I chose Chosen

1 to 2 weeks of evaluation first

What I gave up

Speed to a demo

Why. Choosing an engine by assumption risks building on the wrong base.

02Cloud engine over on-device

What I chose Chosen

Pick the winner of the accent test; keep Apple's engine as an offline backup

What I gave up

Free, private, offline-first

Why. Accuracy on local accents is the whole product.

03Pricing model

What I chose Chosen

Monthly plans with an hours allowance

What I gave up

A simple one-time price

Why. Every hour of audio costs money. A one-time price loses money on heavy users.

04Differentiation

What I chose Chosen

Win on output: summaries, action items, exports for one user group

What I gave up

Competing on raw transcription

Why. Phone makers keep improving free recorders. Raw transcripts will become a commodity.

Product shape

If we build: compete above the transcript

The transcript itself is becoming free: phone makers keep improving their built-in recorders. So the engine layer is a cost to manage, and the product is what sits on top of it.

CAPTUREPhone recorderlectures, callsENGINETest winnercloud, accent-tunedApple on-deviceoffline backupTranscripta commodityphone makersgive this awayWHERE WE COMPETESummariesAction itemsExportsfor one user group
The architecture if the study says build. Capture and transcription are swappable and commoditising; the value, and the reason to pay, sits in the output layer for one user group.

Unit economics

What one heavy user costs

One 1-hour lecture a day for a month (about 22 hours) costs about Rs 660 on Sarvam or about $4 on OpenAI's mini model at list prices.

To keep audio under 40% of revenue, that heavy user's plan would need to cost about Rs 1,650 a month on Sarvam, or about $10 on OpenAI's mini model. Students rate their willingness to pay low to medium, so Sarvam cannot serve heavy student use profitably without an hours cap. Prices at that level point to sales and client-facing professionals, which is why the buyer interviews go to them.

What I learned

So far

  • Writing the build, pivot or kill rule before testing keeps the study honest.
  • Averages hide the problem. The test is designed around the users a general engine fails, not the typical case.

Roadmap

Now, next, later

Now

  • Finish the accent test
  • Fill the WER table

Next

  • Make the build, pivot or kill call
  • Publish it here, with the number

Later

  • If build: a pilot with one student cohort
  • If pivot: summaries on top of free transcripts