01Test before build
1 to 2 weeks of evaluation first
Why: Choosing an engine by assumption risks building on the wrong base.
Trade-off: Speed to a demo
Case 05 · Discovery · In progress · 2026 · 6 min read
Voice capture for Hinglish
Problem statement
Testing speech recognition for Indian accents and Hindi-English conversations.
Problem
Capture ideas in the language you speak
Indian speakers often switch between Hindi and English in the same recording. They need transcripts that preserve the meaning without a long manual correction pass.
Issue
Mixed-language accuracy is the key question
Accents and language switching can introduce transcription errors. Before building another recording app, the study must establish whether a different engine delivers a meaningful improvement.
Solution
Compare engines before building
The proposed product starts with a four-engine comparison on the same real recordings. Accuracy, correction effort and willingness to pay will guide whether to build a dedicated voice-capture experience.
Progress Research planned; recordings and engine tests come next.
- Role
- 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
Hindi-English recordings need more reliable transcription
- Indian accents and Hindi-English switching can reduce transcription quality.
- My own long recordings exposed frequent corrections.
- The study will test whether a dedicated product offers enough improvement.
Users
Students can test accuracy; sales professionals can test willingness to pay
Diagram guide
The horizontal axis is how easy a group is for me to reach; the vertical axis is how much they would pay. Students sit bottom right: easy to reach, so they test transcript accuracy. Sales professionals sit top left: harder to reach but most willing to pay, so I interview them directly. The dashed arrow shows the split: accuracy from students, willingness to pay from sales.| Segment | Use case | Willingness to pay |
|---|---|---|
| Students (for testing) | Record lectures, get notes and summaries | Low to medium; easy to reach |
| Sales and client-facing professionals | Calls and meetings in mixed language | High. Globally, sales teams bring most AI notetaker revenue (Sacra on Otter.ai) |
| Field workers and SMB owners | Voice notes instead of typing | Medium; large but harder to reach |
Hypotheses
Accuracy gains and buyer demand must justify a dedicated product
- 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
Compare four engines on the same clips and interview potential buyers
Diagram guide
Read left to right. Real clips and an open Indian-accent dataset feed all four engines, including Apple's free engine as the baseline. Every engine is scored the same way: word error rate by accent and by language mix, plus speed and cost per hour. The decision rule on the right was written before any clip was tested, so one number drives the call: build, pivot or kill.- 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 answer the same workflow questions, but their answers are not evidence of willingness to pay.
- Accent test20 to 30 real clips (lectures, client calls, Hindi-English mixes) from speakers across India, plus open Indian-accent data such as AI4Bharat's Svarah set.
- 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.
- MetricWord error rate (WER) by accent and by language mix, plus speed and cost per hour.
Decision rule
Set the build decision before seeing the engine results
| If the data shows | Then |
|---|---|
| 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 | Build 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 | Kill for now: 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
Compare recognition quality alongside processing cost
| Engine | Built for | Cost per hour (list, Oct 2026) | WER |
|---|---|---|---|
| Sarvam | Indian languages | Rs 30 | In testing |
| OpenAI mini transcribe | General, multilingual | About $0.18 ($0.003 a minute) | In testing |
| Deepgram Nova-3 | General, with a Hinglish mode | About $0.46 ($0.0077 a minute) | In testing |
| Apple built-in | On-device baseline | Free | In testing |
Unit economics
Heavy audio usage makes buyer selection central to pricing
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 heavy student use cannot be profitable without an hours cap. Prices at that level point to sales and client-facing professionals, which is why the buyer interviews go to them.
Decisions and trade-offs
Test the accent advantage before building the capture app
02Cloud engine over on-device
Pick the winner of the accent test; keep Apple's engine as an offline backup
Why: Accuracy on local accents is the whole product.
Trade-off: Free, private, offline-first
03Pricing model
Monthly plans with an hours allowance
Why: Every hour of audio costs money. A one-time price loses money on heavy users.
Trade-off: A simple one-time price
04Differentiation
Win on output: summaries, action items, exports for one user group
Why: Phone makers keep improving free recorders. Raw transcripts will become a commodity.
Trade-off: Competing on raw transcription
Diagram guide
Read left to right. Audio is captured on a phone, sent to the engine that won the accent test (Apple on-device is the offline backup), and becomes a transcript. The transcript is a commodity that phone makers give away, so the product competes in the dashed area on the right: summaries, action items and exports for one user group.Status and next
Finish the recordings, score the engines and make the build decision
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
So far I have learned: writing the build, pivot or kill rule before testing keeps the study honest, and averages hide the problem, so the test is built around the users a general engine fails.