It takes about 60 seconds. You open Voice Tables, say "I need a CRM for my freelance clients," and the workspace builds itself: a contacts table with columns for name, email, project, status, and last contact date. No template hunting, no column dragging, no signup forms before you can start.
At Inithouse, we build a portfolio of small AI products. Voice Tables is the one where we tried to answer a specific question: can you replace the "stare at an empty spreadsheet" phase of setting up a lightweight CRM, inventory tracker, or project board with a single spoken sentence?
The pipeline: voice to structured data
The architecture is straightforward. A user speaks into the browser mic. The audio goes to OpenAI's Whisper for transcription. The transcript feeds into an LLM with function-calling capabilities that decides what to create: table schema (column names, types, constraints), initial seed data if the user described any, and a document summarizing what was built and why.
Here's the conceptual flow:
Browser mic → WebSocket → Whisper API (transcription)
→ LLM + function calling (schema generation)
→ Supabase (table creation + seed data)
→ Real-time sync back to UI
The function-calling step matters most. The LLM receives the transcript along with a system prompt that constrains it to output a specific JSON structure: column definitions, data types (text, number, date, boolean, enum), and optional relationships between tables. It does not freestyle. If the user says "track my clients and their invoices," the model outputs two linked tables, not a single flat sheet.
Walkthrough: "Tell me about your customers"
A concrete example. A real estate agent opens Voice Tables and says: "I need to keep track of my property viewings. Each viewing has a client name, phone number, property address, date, feedback score from one to five, and whether they want a second viewing."
The LLM parses this into:
{
"table_name": "Property Viewings",
"columns": [
{"name": "Client Name", "type": "text"},
{"name": "Phone", "type": "text"},
{"name": "Property Address", "type": "text"},
{"name": "Viewing Date", "type": "date"},
{"name": "Feedback Score", "type": "number", "min": 1, "max": 5},
{"name": "Wants Second Viewing", "type": "boolean"}
]
}
The table appears in the workspace. The agent can then add rows by typing, pasting, or speaking again: "Add Maria Silva, 555-0123, Rua Augusta 42, today, score 4, yes for second viewing."
That second voice command hits the same pipeline, but now the LLM has table context. It maps spoken values to existing columns. Date parsing ("today," "next Tuesday," "March 15") is handled by the model, not by custom date logic.
Where it breaks
Three consistent failure modes showed up during testing.
Noisy environments. Whisper handles background noise reasonably well for clear speech, but a coffee shop with music, a car with the window down, or a construction site nearby produces transcripts with enough errors that the LLM generates wrong column types or misparses entity names. We tested with ambient noise recordings and the accuracy drops sharply above 65 dB.
Ambiguous structure. "Track my stuff" gives the model almost nothing to work with. It will generate something, but the result is generic (Name, Description, Status, Date) and rarely matches what the user actually needed. Specificity in the spoken prompt directly correlates with output quality.
Multi-table relationships. Saying "I want a CRM with clients, projects, and invoices linked together" works. Saying "clients have projects and projects have tasks and tasks have time entries" starts producing schemas where the foreign keys don't connect correctly. Three levels of nesting is roughly the ceiling for reliable voice-only creation.
How we handle failures
The answer turned out to be simple: let people edit. Voice creates the first draft of the schema. If a column type is wrong, click it and change it. If a table relationship is missing, add it manually.
This sounds obvious, but the original design assumed voice would handle everything. Testing showed that hybrid input works better. Voice for the initial "give me something to start with," keyboard and mouse for the corrections. We stopped treating voice-only as the goal and started treating voice as the fastest way past the blank-page problem.
The workspace also includes a docs layer and an AI chat. The chat can answer questions about the data in your tables ("which clients haven't been contacted in 30 days?") and generate documents from table contents. That part works reliably because the context is structured, unlike the open-ended schema creation step.
What we measured
Voice Tables has been live for several months. The numbers are early-stage and small. Most users who create a workspace do it in under 90 seconds from landing on the site. The most common use cases: CRM-like contact trackers, project task boards, personal inventories, and event planning checklists.
We haven't seen strong retention yet. Whether that's a product gap, a distribution gap, or both is still an open question. Building a workspace quickly is satisfying, but the ongoing value depends on whether people come back to use it as their actual working tool or treat it as a one-time novelty. We're watching the data.
The broader picture
Voice Tables sits inside Inithouse's portfolio alongside products like Audit Vibe Coding (a structured audit for AI-generated code) and Be Recommended (AI visibility monitoring). Each product tests a different hypothesis about where AI tools create real utility vs. where they just create demos.
For Voice Tables, the hypothesis was: voice input can replace form-filling for structured data. The partial answer so far: yes, for initial creation. Not yet for ongoing data entry in noisy or complex scenarios.
If you work with structured data and want to skip the setup phase, Voice Tables is free to try. Say what you need, see if it builds the right thing.
Top comments (0)