Case Study No. 002
Convoice AI: making voice automation useful enough to buy.
I co-founded Convoice and led software engineering. The job was not to make an AI voice demo. It was to build something businesses could actually use: low-latency, affordable, operationally clear, and credible enough to earn a place in real workflows.
Inbound / Outbound
Voice Automation
Convoice
01 The Challenge
Most voice AI products are easy to demo and hard to trust. That was the real problem. Businesses did not need another interesting conversation toy. They needed something that could sit inside support or sales operations without feeling slow, brittle, or too expensive to run.
- arrow_forward Latency had to feel natural enough that the system still sounded competent.
- arrow_forward Infrastructure had to support a believable cost model for smaller businesses.
- arrow_forward Product positioning had to stay tied to concrete workflows, not vague AI promises.
The Approach
The work sat at the intersection of system design and product design. I cared about the same question from both directions: what kind of architecture lets the product feel fast, clear, and worth paying for?
Product Lens
Start from the workflow. What job is the voice system actually taking off someone’s plate?
Technical Lens
Latency is part of trust. A voice assistant that answers too slowly already feels wrong.
Cost Lens
Infrastructure was never just backend plumbing. It shaped whether the business model could survive.
Team Lens
The product had to stay coherent across engineering, branding, interface, and go to market conversations.
Good voice automation is not about sounding human. It is about making the system feel reliable enough that people stop thinking about the interface and start trusting the work.
Why It Was Interesting
Convoice was one of those projects where engineering choices had obvious business meaning. Public writeups on the system describe an early low-latency LLM-to-voice architecture built mostly on serverless AWS infrastructure. That mattered because it tied the technical stack directly to responsiveness and pricing, instead of treating architecture like a hidden implementation detail.
That is the kind of problem I like. Not “how do we deploy a model,” but “how do we design a system whose latency profile, cost structure, and product surface all reinforce each other?” When those things line up, the product starts to make sense. When they do not, no amount of AI polish saves it.
It also says something about how I like to work. I am most interested in systems that do real work, make their logic legible, and create leverage instead of theater.
Voice was the interface, but workflow fit was the product.
Responsiveness was part of credibility, not just a performance metric.
System design, product design, and business viability had to be solved together.