AI Voice App in 650 Commits: Solo Dev Feedback
Key takeaways: Building a voice-powered AI task manager solo involved 650+ commits, a real-time audio pipeline (Deepgram + OpenRouter + OpenAI TTS), a React Native New Architecture, and most importantly, 6 months of lessons on what not to do. This article covers the complete stack, costly mistakes, and the decisions that made all the difference.
Six months ago, I had a simple problem. At home, there were four of us, and we used sticky notes on the fridge for groceries. At the diving club, everything went through WhatsApp — it was impossible to find information from three days ago. Existing apps? Too complicated, too many clicks, not adapted to real life.
Today, TAMSIV is a complete Android app with an AI voice assistant, hierarchical collaborative groups, a recurring calendar, gamification, and it speaks 6 languages. Over 650 commits. Solo dev. And I'm going to tell you exactly how I got here.
Why create a voice-powered task manager in 2025?
The short answer: because classic productivity apps assume you're sitting in front of a screen with both hands free. But in real life, you're driving, cooking, walking the dog, or carrying groceries.
I tested dozens of apps — Todoist, Any.do, Google Tasks, Microsoft To Do. All excellent on paper. But none of them put voice at the center. They might have had a microphone button hidden somewhere, but the main interaction remained the keyboard.
My bet: voice as the primary interface. You press, you speak, the AI understands and creates the task. No forms, no dropdowns, no friction. If you want to know more about why classic productivity apps fail, I talk about it in this article on productivity app fatigue.
What technical stack for an AI voice app?
Choosing the right stack is the most important decision. Here's what I learned after 6 months:
- Frontend: React Native 0.81 (TypeScript) with the New Architecture (Fabric). Native performance, a single codebase. The choice was obvious because I know React and wanted to deliver quickly.
- Backend: Node.js/Express + WebSocket. WebSocket is essential for real-time audio streaming — HTTP is not enough.
- Database: Supabase PostgreSQL with 3 separate schemas (
privat,collaborative,gamification). I explain this architecture in detail in my article on database structuring. - Website: Next.js 16 + Tailwind CSS 4, deployed on Vercel. I recounted its 3-day build in this dedicated article.
How does the app's voice pipeline work?
This is the technical core of the project. The user presses the button, speaks, and receives a structured voice response in 1.5 to 3 seconds. Under the hood:
Audio PCM 16kHz mono → WebSocket (JWT) → Deepgram STT (VAD) → OpenRouter LLM → Function calling → OpenAI TTS → Voice response- Audio capture: The phone sends raw audio chunks in 16-bit, 16kHz, mono PCM via WebSocket.
- Speech-to-Text: Deepgram transcribes in streaming with automatic voice activity detection (VAD).
- LLM: OpenRouter routes to 400+ models with automatic fallback. The model understands the intent and uses function calling to create tasks, memos, or events.
- Text-to-Speech: OpenAI TTS ("nova" voice) generates the audio response, streamed back via the same WebSocket.
Each step can fail independently. I implemented intelligent retries, circuit breakers, and fallbacks at every level. For the complete technical details of the pipeline, read the article dedicated to the voice pipeline.
Which features required the most work?
In 650+ commits, some features swallowed entire weeks. Here are the top 3.
Hierarchical collaborative groups
On paper: "add groups". In reality: a 6-level deep hierarchical system with 4 roles (Admin, Manager, Member, Viewer), recursive PostgreSQL queries (CTE), and 31 RLS policies to write and test individually.
My diving club was the perfect use case: Club → Technical Committee → Level 1 → Tuesday Group. Permission inheritance between levels was the real headache. I talk about it in depth in the article on hierarchical groups.
Recurring calendar
LLMs are not good with dates. When you say "every Tuesday at 2 PM", the model needs to understand the recurrence, the timezone, and generate the correct occurrences. I had to build a mapping table and a robust validation system. The technical details are in the article on the calendar and filters.
Gamification
12 levels, 10 badges, streaks up to 365 days, daily challenges, and a leaderboard. A dedicated schema with 5 tables and automatic triggers. Gamification is not a gimmick — it fundamentally changes user engagement. I detailed the architecture in the article on the gamification schema.
What mistakes to avoid when developing solo?
I'll be honest: I made costly mistakes. If you're developing a solo project, learn from my failures.
Mistake #1: Zero marketing for 6 months
650 commits and not a single post talking about it. None. I was so absorbed by the code that I completely ignored the visibility part. The day I wanted to communicate, I was starting from scratch — zero audience, zero content, zero history.
The lesson: start marketing from the first commit. Even a simple "I'm starting a new project" tweet is better than silence.
Mistake #2: Underestimating internationalization
Going from 100% French to 6 languages (FR, EN, DE, ES, IT, PT) affected 35 files and 1993 translation keys. It's a huge undertaking when you do it after the fact. Today, every new feature is translated from the start. i18n has become a real acquisition channel — I talk about it in this article on i18n as a growth lever.
Mistake #3: Not structuring the database from the start
I was lucky to make this choice well, but I've seen so many projects where everything is in the public schema that I have to mention it. Three separate schemas from day 1 change everything for maintainability. The details are in the article on database restructuring.
How to manage a solo project of this magnitude?
650 commits in 6 months means an average of 3-4 commits per day. Some days I made 10, others zero. Here's what helped me:
- Atomic commits: each commit does one thing. This makes debugging and reverting much simpler.
- A monorepo: frontend, backend, and website in the same repo. A single
git logto see the complete project history. - Singleton services:
ConversationService,CalendarService,GamificationService... each domain has its dedicated service, easy to test and maintain. - The PendingCreation pattern: voice creates a preview, the user validates, edits, or cancels before saving to the database. Zero surprises.
What is the operating cost of an AI voice app?
A question everyone asks. Here's the breakdown per voice interaction:
- Native STT (device): free. Deepgram cloud as fallback: ~$0.0059/min.
- LLM via OpenRouter: variable depending on the model, typically $0.001-0.01 per request.
- TTS OpenAI: ~$0.015 per 1000 characters.
- Supabase: generous free plan, then ~$25/month for Pro.
- Backend Railway: ~$5-10/month depending on usage.
In total, a complete voice interaction costs between $0.01 and $0.03. This is viable with a freemium model — I detailed the subscription tiers in the article on RevenueCat and subscriptions.
Where is the project today?
TAMSIV is in alpha on the Google Play Store. 12 active testers. Public production launch is imminent.
The metrics that matter:
- 650+ commits on the monorepo
- 6 languages supported (FR, EN, DE, ES, IT, PT)
- 3 WebSocket modes (Live, Realtime, Batch)
- 31 RLS policies for data security
- 12 gamification levels with badges and streaks
- 6 tabs: Dictaphone, Feed, Calendar, Groups, Social, Profile
FAQ
How long does it take to build an AI voice app solo?
For TAMSIV, it took 6 months full-time. The voice pipeline alone (STT + LLM + TTS) took about 3 weeks. Collaborative groups and gamification each added 2 months. If you focus on the voice MVP only, count 2-3 months.
Why React Native rather than Flutter or native?
I already knew React. React Native 0.81's New Architecture (Fabric) offers near-native performance. Flutter was a valid option, but the npm ecosystem and the React community tipped the scales. Pure native would have doubled development time without significant advantage for this type of app.
Is native Speech-to-Text as good as Deepgram?
For most cases, the device's native STT is sufficient and free. Deepgram excels in noisy environments and for non-European languages. TAMSIV uses native by default and switches to Deepgram as a fallback. I compared the two in detail in the article on native STT vs Deepgram.
How to monetize an AI voice app without exploding costs?
The freemium model with daily limits on the free plan. Costly features (cloud STT, AI image generation) are reserved for Pro and Team plans. RevenueCat manages in-app subscriptions. The secret is to optimize the cost per interaction — free native STT covers 90% of usage.
Do you need a backend for a voice app, or can everything run locally?
You need a backend for the LLM (function calling, orchestration) and TTS (APIs are server-side). STT can run locally. WebSocket is essential for real-time streaming — classic HTTP calls add too much latency.