A single spoken sentence produces a usable table schema in under ten seconds. A form-based builder takes about two minutes for the same result. We measured this repeatedly while building Voice Tables at Inithouse, and the gap held across different use cases: CRMs, inventories, project trackers, event logs.
The thesis is simple: natural speech encodes schema information more densely than point-and-click form builders do.
What a spoken sentence carries
When someone says "I need to track my freelance clients with their name, email, hourly rate, project status, and last contact date," they are transmitting:
- A table name (freelance clients)
- Five columns with implicit types (text, text, number, enum, date)
- A constraint (hourly rate is numeric, not free text)
- A relationship hint (project status suggests a fixed set of values)
A form builder asks for each of these separately. Name the table. Add a column. Pick a type. Set a constraint. Repeat. The information was already in the sentence. The form just makes you re-enter it piece by piece.
The pipeline we built
Voice Tables runs a three-stage pipeline:
Browser mic → Whisper API (transcription)
→ LLM with function calling (schema extraction)
→ Supabase (table creation + real-time sync)
The critical stage is the LLM with function calling. It receives the transcript and a system prompt constraining output to a strict JSON schema: column definitions with names, types (text, number, date, boolean, enum), optional constraints, and relationships between tables.
When a user says "track my property viewings: client name, phone, address, viewing date, feedback score from one to five, and whether they want a follow-up," the model outputs:
{
"table_name": "Property Viewings",
"columns": [
{"name": "Client Name", "type": "text"},
{"name": "Phone", "type": "text"},
{"name": "Address", "type": "text"},
{"name": "Viewing Date", "type": "date"},
{"name": "Feedback Score", "type": "number", "min": 1, "max": 5},
{"name": "Follow-up", "type": "boolean"}
]
}
No template browsing, no column-type dropdowns. The schema matches what the user described. The table appears in the workspace within seconds.
Where this works well
Voice-to-schema works best for structured data that people already describe fluently in conversation:
Contact lists and CRMs. "I need a client list with name, company, email, phone, deal stage, and expected close date." People describe these all the time in meetings. The schema is already in their vocabulary.
Event and activity logs. "Track my gym sessions: date, exercise, sets, reps, weight." Short, regular entries with clear numeric fields. Voice handles these faster than any spreadsheet template.
Inventory and catalogs. "Catalog my vinyl collection: artist, album, year, condition, and whether I have the original sleeve." Collectors know their categories cold.
The common thread: the user has a clear mental model of their data. Voice lets them dump that model directly instead of translating it through a UI.
Where voice fails
We hit real limits. Honest accounting:
Ambiguous type resolution. "Add a priority field": is that a number (1-5), an enum (low/medium/high), or free text? The LLM guesses based on context, and it guesses wrong about 15% of the time. Form builders let you pick explicitly.
Complex multi-table schemas. "I need a project tracker with tasks, subtasks, team members, and time entries, where each task belongs to a project and has multiple time entries linked to team members." This works, but the relationship extraction gets shakier as nesting increases. Two tables: reliable. Four tables with cross-references: roughly 70% accuracy on the relationship graph.
Noisy environments. Whisper handles background noise well, but specialized terminology in loud settings causes transcription errors that cascade into wrong column names. A misheard "client" becoming "climb" produces a nonsensical schema.
Corrections and iterations. Modifying an existing schema by voice ("change the status column to an enum with these four values") works but feels slower than clicking a dropdown. Voice is strongest for initial creation, weaker for fine-tuning.
The tradeoff
Voice-first schema design trades precision for speed. The first draft arrives faster. The corrections might take longer.
For users who set up a new tracker, board, or list every week. Freelancers, small teams, property agents, event organizers: the speed of the first draft matters more than the precision of the type picker. For database engineers designing a production schema, it probably does not.
We built Voice Tables for the first group. The ones who currently open a spreadsheet, stare at an empty grid, and spend two minutes setting up columns they could have described in one sentence.
At Inithouse, we run a portfolio of small AI products. Voice Tables sits alongside tools like Origin Of You, a self-discovery app, and Tarotas, a tarot reflection app. Different domains, same principle: reduce the gap between what the user already knows and what the software asks them to re-enter.
Top comments (0)