A voice-first PDF assistant built with Next.js 16. This documentation explains how the system works today, the trade-offs behind the current design, and the engineering path toward faster retrieval, lower voice latency, and stronger reliability.

Documentation map

Current Architecture

Current Architecture Trade off

WhisperDocs V2 - Production Architecture & Goals

Security & Reliability

Testing & Engineering Quality

System at a glance

Browser
  ├── Next.js UI / PDF parsing
  ├── Clerk-authenticated app requests
  └── Direct voice connection → Vapi

Next.js server
  ├── Server Actions / API routes
  ├── MongoDB / Mongoose
  ├── Vercel Blob
  └── Secure Vapi document-search tool

Vapi
  └── STT → LLM → tool call when document context is required → TTS

Engineering focus

The most important architectural boundary is the voice retrieval path: real-time audio stays between the browser and Vapi, while document authorization and retrieval re-enter the application server through a signed, server-to-server tool call.

The most important future work is to move heavy PDF ingestion out of the synchronous request path, improve retrieval quality and speed, and add tracing so voice latency can be measured stage by stage.