At Inithouse, a studio shipping a growing portfolio of products in parallel, we kept running into the same problem: people who need structured data but hate spreadsheets. Field workers, coaches, small business owners. They know what they want to track. They just do not want to learn a new tool to do it.
So we built Voice Tables, an AI workspace where you describe what you need and it builds the tables, docs and data for you. The core idea: speak your data instead of typing it into cells.
Before we settled on our approach, we evaluated three alternatives. Here is what we found and why we went a different direction.
Option 1: Firebase + a voice API
The obvious developer move. Plug Whisper or Google Speech-to-Text into a Firebase backend, write some Cloud Functions to parse the transcript, and store the result.
It works. We prototyped this. The speech-to-text part was easy. The problem was everything after: mapping a sentence like "add 3 pallets of oak flooring, delivered Tuesday, warehouse B" into the right table, the right columns, with the right types. That mapping logic is where you spend 80% of the effort, and it is different for every use case.
You end up building a custom NLU layer per schema. For a single app, fine. For a tool that needs to handle arbitrary user-defined schemas, it does not scale.
Option 2: Supabase + Whisper
We use Supabase heavily across our portfolio (including at Verdict Buddy, our AI conflict mediator). The Postgres backend and edge functions are solid. Wiring up Whisper for transcription is straightforward.
Same problem as Firebase though: the backend is not the bottleneck. Supabase gives you great infrastructure for storing and querying data. But the hard part is the layer between "user said something" and "here is a structured row to insert." That is a UX problem disguised as a backend problem.
If your team has the capacity to build and maintain that middle layer for one specific domain, Supabase + Whisper is a legitimate stack. We have shipped projects on it. But for a general-purpose voice-first workspace, we needed the intelligence baked into the product itself.
Option 3: Custom voice assistants
Enterprise voice assistants (think Alexa for Business, custom Google Assistant actions, or purpose-built solutions) can handle voice-to-data flows. They are powerful when you have a narrow, well-defined domain.
The trade-offs: expensive to build, expensive to maintain, and locked to specific platforms or hardware. For a small business owner who wants to track inventory by talking to their phone, the setup cost does not make sense. They need something that works in a browser tab, not a six-month integration project.
What we built instead
Voice Tables takes a different approach. Instead of bolting voice onto an existing database tool, we built the data layer around voice from the start.
The pipeline: Whisper handles transcription. An LLM function-calling layer handles the hard part, mapping natural language to structured operations against the user's schema. The user says "add a new client, Maria, plumber, met her at the trade show last week." The system figures out which table, which columns, what types, and inserts the row.
The key technical insight we arrived at: speech-to-text is a solved problem. Text-to-structured-data-entry is the unsolved one. Every approach we evaluated treated voice as an input modality bolted onto a traditional data entry flow. We found that if you design the data model to expect natural language from the start, the whole UX changes.
We are honest about what is still rough: the system sometimes asks for clarification when the schema is ambiguous, complex multi-table operations need more work, and offline mode (which we support) falls back to queuing rather than real-time processing. These are active areas of development.
When to pick what
If you are building a single-purpose app with a fixed schema and your team can maintain the NLU layer, Firebase or Supabase + Whisper will serve you well. The infrastructure is solid and you control every piece.
If you need a voice-first workspace that handles arbitrary schemas without custom development, that is the problem Voice Tables was built to solve.
Inithouse is a studio running parallel product experiments. We observed across our portfolio that the tools people actually use are the ones with the lowest friction to get data in. Voice turns out to be the lowest friction input for a lot of real-world contexts where a keyboard is not practical.
Top comments (0)