Vaanistack

A pre-MVP observation about the Indic voice AI ecosystem we keep coming back to: the research is further ahead than the deployment infrastructure. There's more public methodology, open datasets, and reproducible research in Indian language AI than most countries get. AI4Bharat has published benchmarks, evaluation methodology, and open models. Bhashini provides translation and speech infrastructure as a public good. The Sarvam team has open-sourced significant model artifacts. Academic groups at IIT-Madras, IIIT-Hyderabad, and IIT-Bombay have built foundational work on Indic NLP (natural language processing) and speech. For someone starting in voice AI today, the public research surface is not the bottleneck. The deployment-grade engineering on top of that research is. What we're noticing in pre-MVP research: 1. The gap between "this works in a notebook" and "this works in a 24/7 call centre" is huge — and it's not primarily a model-quality gap. It's about telephony integration, latency under load, deterministic failure modes, observability, and the boring engineering of running a service. 2. Most academic Indic voice work is monolingual or pure code-switch. Production Indian voice is hybrid — Hindi, English, Hinglish, and a regional language in a single utterance — and the eval surface for that hybrid audio is thin in the public ecosystem. 3. The buyer-facing harness around voice AI in India is underbuilt. Documentation, security questionnaires, deployment options, observability dashboards, support runbooks — these are the layers that determine whether a great model becomes a deployed product. This shapes what we think VaaniStack is for. We are not trying to advance the research frontier of speech-to-text — we benefit from the work happening at AI4Bharat and academic groups, and we intend to contribute back. We are trying to build the deployment-grade engineering and the buyer-facing harness on top of multilingual code-switched speech intelligence. The research community has done the hard part of moving the floor. The harness work is where the open lane is. That is the lane we are running in. If you are part of the Indic voice or NLP research community and would consider letting us cite your methodology, contribute back to eval sets, or just compare notes — we would value that. DM us. #VoiceAI #IndicLanguages #IndicAI #BuildingInPublic

A short note from pre-MVP at VaaniStack on something we've been getting more deliberate about: what we're NOT doing. The instinct in pre-MVP is to keep saying yes. Every adjacent capability sounds important. Every buyer-discovery conversation surfaces a new "if you could also do X" idea. Every paper we read suggests a new architectural option worth exploring. The result, if you're not careful, is a roadmap that reads like a complete speech-AI ecosystem and a team that can't ship any of it well. We've been doing a different exercise: writing down what we're explicitly NOT doing this quarter, and why. Things we're not building at VaaniStack right now: 1. Our own large language model (LLM). Several Indic LLM efforts already exist (Sarvam-30B, AI4Bharat's IndicLLaMA work, the open ecosystem around Llama and Qwen). We will integrate with one or more of these. We will not try to be a foundation-model company at the same time as a voice-intelligence one. 2. Document AI, OCR (optical character recognition), dubbing, content-moderation voice. These are all valid adjacencies. They are not voice infrastructure for live conversations, which is the lane we're staking. Scope discipline now to avoid a thin product across many domains. 3. Coverage of every Indic language at launch. Twenty-two languages at average quality is not a wedge. Hindi, English, Hinglish, and one regional language at measurable depth — with a credible roadmap to the next ones — is. 4. A monolingual product variant. We had considered shipping a "pure Hindi" model for buyers who said they only needed Hindi. After more discovery conversations, we don't think the actual buyer wants this — they want one model that handles whatever language the customer actually speaks, with a confidence signal per language span. 5. A pricing race to the floor. Sarvam is at the price floor in the commercial Indic voice market. We are not racing them there. We are racing on harness depth and predictability. The reason to share this in a company post: pre-MVP scope discipline is harder than it sounds, and writing it down publicly makes it harder to quietly walk back. The "yes" list shrinks. The "no" list earns its keep. If you've shipped pre-MVP scope discipline that held up under pressure — we'd love to hear how. DM us. #VoiceAI #IndicLanguages #BuildingInPublic

A pattern we keep noticing in pre-MVP buyer discovery — and one we're still figuring out how to act on. Most voice AI vendor pitches lead with accuracy averages. WER (word error rate) at 8.1%. Latency at 200ms. Language coverage at 22 languages. The implied framing is "lower number wins" or "more languages wins." The buyer conversations we've been having don't sound like that. The actual concerns from operations and compliance leads sound more like: - "When it gets a transcription wrong, can we tell? Is there a confidence signal we can act on?" - "When the call audio degrades — packet loss, codec switch, background noise — does the model degrade gradually or fall off a cliff?" - "If a specific failure happens during pilot, can your team reproduce it on demand for the post-mortem?" - "When we add a new word to our domain vocabulary, how long until it's reflected in production transcription?" What these have in common: they aren't asking for higher accuracy. They're asking for predictability under failure. A 92% model that fails predictably is easier to deploy than a 95% model that fails unpredictably — because the operations team can build runbooks around predictable failure but cannot build runbooks around magic regressions. This changes what we're building toward at VaaniStack, more than we expected at the start of pre-MVP. The instrumentation matters more than we'd planned: confidence per language span, graceful degradation telemetry, deterministic reproduction of edge cases, a vocabulary-update path with measurable latency. None of this shows up on a public benchmark leaderboard. All of it shows up in a procurement conversation. We're still figuring out the right way to instrument and communicate this — and whether to weight some of it ahead of raw accuracy in the early versions of the model. Open question. If you've shipped voice AI into Indian enterprise and have thoughts on how buyers actually weight accuracy vs predictability — we'd genuinely value the input. DM us. #VoiceAI #IndicLanguages #BuildingInPublic

A pre-MVP update from VaaniStack — and a list of things we're still figuring out, not announcing. We're early. Not "soft launch" early — actually pre-MVP, weeks of model and methodology work ahead before we have anything to put on a public dashboard. We're using this stretch to think out loud about the open questions, because the answers will shape what we build first and what we hold back. Five questions we're chewing on: 1. Vertical pack sequencing. NBFC (non-banking financial company) collections is the obvious first vertical because the failure modes are clear and the buyer is technical. But healthcare triage has a more interesting safety boundary, and BPO (business process outsourcing) inbound has a wider deployment surface. We're not sure yet whether the right first vertical is the cleanest, the safest, or the broadest. We have a guess. We don't have conviction. 2. Streaming-first or batch-first. A streaming-first architecture is harder to build but matches the production reality of live voice agents. A batch-first architecture ships earlier but locks us into a positioning we don't actually want. We're leaning streaming-first. We haven't committed. 3. How much of the eval set to open-source. Reproducibility is a product feature for us, which argues for opening the eval set. But opening a vertical-specific eval set with real call audio raises consent and competitive-moat questions. We're working through it carefully. 4. Confidence scoring per language span. The architectural piece we keep returning to. If the STT (speech-to-text) returns a confidence score per language span, downstream NLU (natural language understanding) can handle the code-switch boundary far more gracefully. We think this is the right design. We haven't built it yet to know. 5. Deployment model defaults. On-prem and VPC (virtual private cloud) deployment are clearly important for Indian enterprise buyers. But making them the default — not the upsell — has cost implications for early customers and for us. We're working through whether default-VPC is sustainable or aspirational at this stage. We're sharing these because the "pre-launch positioning" version of a company post pretends the answers are figured out. They aren't. We'd rather say what we're thinking than what we're pretending. If you've shipped voice AI infrastructure into Indian enterprise and have opinions on any of these five — we'd genuinely value the input. DM us. #VoiceAI #IndicLanguages #BuildingInPublic

Healthcare triage voice AI in India has constraints other verticals don't — and most of them aren't about accuracy averages. We've been thinking about this as part of mapping which vertical packs VaaniStack ships in what order. Some failure modes in healthcare voice that don't show up the same way in NBFC collections or BPO inbound: 1. Prescription and dosage transcription. A model that gets "twice daily" and "two doses daily" wrong is a clinical safety issue, not a quality-of-service issue. The model needs to refuse to transcribe a dose if confidence is below threshold, not produce its best guess. 2. Vernacular medical terminology and code-switching. Patients describe symptoms in colloquial Hindi-English — "pet mein bahut bharipan" — and the triage system needs to bridge that to clinical terminology like "epigastric distension" before it can route, attached to the right ICD (International Classification of Diseases) code. The model has to know the audio domain and the patient register, not just the language. 3. Three-way calls. Family member, patient, triage agent — three speakers, two languages, often a live translation happening in the call. Speaker attribution has to be precise because consent and instructions attach to specific speakers. 4. Compliance and confidentiality. Patient data is protected under the DPDP (Digital Personal Data Protection Act) and increasingly under sector-specific guidance. The data-flow questions are stricter than NBFC, the retention defaults shorter, the redaction policies more aggressive. How we're approaching healthcare triage as a vertical pack: - The base model is the same multilingual code-switched ASR (automatic speech recognition) shipping at launch. - A healthcare-specific vocabulary, a dosage-validation layer, and a confidence-threshold policy ride on top. - Audio never leaves the customer's environment by default — VPC (virtual private cloud) and on-prem deployment are the assumed mode for healthcare, not the upsell. - Documented data-flow diagrams and consent paths before any pilot starts. The compliance conversation is a Day 1 conversation, not a Week 8 one. NBFC collections is the first vertical pack we're building. Healthcare triage is on the immediate roadmap behind it. Same architecture, different domain layer. If you're building voice-enabled patient triage, hospital intake, or telemedicine flows and the language reality of your callers is multilingual and code-switched — we'd love to talk. DM us or join the waitlist. #VoiceAI #HealthcareAI #DPDP #BuildingInPublic

An observation from buyer-discovery conversations in pre-launch — the conversation around voice AI procurement in Indian enterprise looks nothing like the vendor pitches assume. Most voice AI vendors design their pitch deck for a CTO who wants to see WER (word error rate) on a clean benchmark, latency on a streaming demo, and a price per minute. That CTO does exist. They are not the buyer. The real conversation runs in parallel across four roles: 1. The CTO or Head of Engineering — does it work on our actual audio, will it integrate with our telephony stack (Asterisk, Twilio, a regional player), what's the failure mode under load. 2. The Head of Operations or Floor Manager — what happens to agent productivity, can the supervisor still listen in, will it route correctly when the customer goes off-script, how does it handle a difficult conversation. 3. The Compliance Officer or DPO (Data Protection Officer) — where is the audio going, what's the data-flow diagram, what's the consent path, can we get the data-processing agreement reviewed by legal before any pilot starts, what's the breach-notification commitment. 4. The CFO or Procurement Lead — what's the all-in cost including telephony, what's the contract structure, what's the exit clause, what's the price escalation path, can this run through a procurement process that takes 8 to 12 weeks. A voice AI vendor that only talks to (1) loses on (2), (3), or (4) and doesn't understand why. A vendor with credible answers ready for all four — actual answers, not marketing language — is the one that gets to a signed pilot. This is the structure VaaniStack is being built around. The harness work (docs, console, security questionnaire, deployment options, contract templates) is not "enterprise polish" — it's what the buyer actually procures. The model is necessary; the harness is what they pay for. Looking for early design partners on the operations and compliance side, not just engineering. DM us or join the waitlist. #VoiceAI #EnterpriseAI #VoiceProcurement #BuildingInPublic

Counterintuitive claim from inside the build: more of our pre-launch engineering hours go into the eval set than into the model itself. Here's why. Public Indic speech benchmarks (AI4Bharat's IndicSUPERB, FLEURS-Indic, Common Voice Hindi) are excellent for what they are — clean, controlled, single-language audio. They're necessary baselines. They're not sufficient for the kind of audio that actually shows up in NBFC collections, BPO inbound, or telemedicine triage. The gap between "scores well on IndicSUPERB" and "works on a Tuesday-morning collections call" is the gap we're building the eval set to close. What that eval set includes: - Code-switched utterances at multiple switch densities — a Hindi sentence with one English word, sentence-by-sentence alternation, full Hinglish at the lexical level. Each of these is a different failure mode, and a single "code-switch eval" lumps them together at significant cost. - Telephony-grade audio at 8 kHz with codec compression (G.711, G.729, Opus narrowband). Not "we downsampled clean audio" — actual codec round-trips. Same script, three codecs, three different numbers. - Background-condition slices: clean, low TV, market noise, multiple speakers in proximity, packet-loss simulation. Production audio rarely arrives in studio condition. - Speaker-change mid-call. The customer hands the phone to a family member. The agent has to know it's a different speaker without breaking the conversation context. - Vertical-domain vocabulary slices — NBFC collections terminology, BPO support scripts, healthcare triage utterances — because generic accuracy averages hide the words that matter most. The principle: every eval slice represents a category of real production failure that shows up in deployed voice systems. If we can't measure it, we can't claim to have solved it. We will publish the eval set alongside the benchmark dashboard before any product claims. Reproducibility is the product. If the methodology can't survive scrutiny, the numbers can't either. If you're running a multilingual voice pipeline today and have audio samples representing your hardest cases — we'd love to add categories we're missing. DM us. #VoiceAI #IndicLanguages #Evaluation #BuildingInPublic

A question that comes up consistently when Indian enterprise voice buyers evaluate any voice API — and one global APIs don't have a clean answer for: "Where does the audio actually leave our network, who processes it, and what are we committing to under DPDP?" DPDP (Digital Personal Data Protection Act) is now the operating reality for any Indian enterprise handling customer voice data. Add CERT-In (Indian Computer Emergency Response Team) audit requirements, BFSI sector-specific data-localisation rules, and the customer's own MSA (master services agreement) data clauses — and the buyer's risk register has 6-8 explicit questions about where the audio goes that any voice API has to answer credibly before procurement signs. Most global voice APIs were not designed for this. The default deployment is "send audio to our US/EU cloud, get transcription back." That's a non-starter for an NBFC (non-banking financial company), a BPO (business process outsourcing) handling EU-origin calls, or any healthcare flow touching patient identifiers. The workaround is usually some combination of regional data-centre add-ons, contractual carve-outs, and prayer — none of which the compliance officer accepts. How we're approaching it at VaaniStack: - On-prem deployment as a first-class mode, not a "let us know if you need that." Same code, packaged as Docker Compose with an offline licence server. - VPC (virtual private cloud) deployment in the customer's AWS / Azure / GCP region, with audio never leaving their cloud boundary. - Documented DPDP alignment — data-flow diagrams, retention policies, encryption-at-rest defaults, redaction defaults — before any pilot starts. - A security questionnaire template we publish openly, so the buyer's procurement team isn't drafting from scratch. The cloud-only voice API model is fine for many use cases. It is not fine for the Indian enterprise buyer's actual risk register. We're building VaaniStack assuming that's where the real production deployments will land — and that on-prem and VPC are where the moat is, not just an enterprise tier upsell. Looking for design partners with active DPDP / data-residency constraints. DM us or join the waitlist. #VoiceAI #DPDP #DataResidency #BuildingInPublic

Everyone says "support Indian languages." Almost no one means what that actually requires. We're building VaaniStack — voice infrastructure for India — and here's the problem in five numbers: — 22 official languages. The 2011 Census recorded ~19,500 mother tongues. The street speaks in thousands. — 250M+ people code-switch daily — Hinglish, mid-sentence. The median utterance, not the edge case. — 65% of Indians use voice search; 40% of rural users rely on voice — literacy, not preference. — Indic-language internet users passed English back in 2016 (234M vs 175M). 70% prefer their mother tongue. — And most of it arrives at 8 kHz — telephony-grade, noisy, code-mixed, packet-loss-prone. Global voice models are tuned for clean, monolingual, wideband audio. India is none of those. We're tuning the stack for exactly this — and the public benchmark dashboard goes live before we make any product claims. If you're running production multilingual voice flows, we're looking for design partners. DM us or join the waitlist. Back to it. #VoiceAI #IndicLanguages #SpeechRecognition #CodeSwitching #BuildingInPublic

A generic voice agent and a voice agent fine-tuned for a specific vertical are different products. Same model architecture, same languages, same accents — but the deployed behaviour is different in ways that matter for the customer experience and the compliance officer. We've been thinking about this as we build VaaniStack. Take NBFC (non-banking financial company) collections as the example. A generic Hindi-English speech-to-text model and a collections-tuned one differ on at least four axes: 1. Vocabulary. The model needs to recognise terms like "EMI moratorium", "DPD bucket", "settlement letter", "rolling-90", "right to information" — and not collapse them into phonetically similar everyday words. Generic models trained on web text rarely do this well. 2. PII redaction. Customer account numbers, Aadhaar fragments, mobile numbers, names — these appear in the audio. A vertical-tuned model can flag and redact at the transcription layer, not as a downstream pass that adds latency and breaks streaming. 3. Compliance branches. Collections calls have legally-required disclosures, opt-out paths, and recording-consent flows. The voice agent has to know which path the conversation is on and which branch it can't deviate from. That's a script-graph problem, not a transcription problem — but the transcription has to surface the right tokens for the script engine. 4. Edge-case behaviour under stress. Customers argue. Customers go silent. Customers hand the phone to a family member mid-call. The generic model treats these as noise. The vertical-tuned model treats them as the actual work. How we're approaching it: a base multilingual ASR (automatic speech recognition) + TTS (text-to-speech) stack, plus vertical packs — bundled vocabulary, PII redaction policies, compliance branches — that fine-tune the base for a specific deployment. NBFC collections is one of the first packs we're building. BPO (business process outsourcing) inbound and healthcare triage are next. We'd rather ship measurable vertical depth than horizontal language breadth. Looking for design partners running NBFC collections or BPO inbound voice flows today. DM us or join the waitlist. #VoiceAI #IndicLanguages #NBFC #BuildingInPublic