DEV Community

Cover image for The Shopkeeper Who Never Gets a Break
Kartik Garg
Kartik Garg

Posted on

The Shopkeeper Who Never Gets a Break

Walk into any small shop in India — a kirana store, a general store, a corner medical shop — and you'll notice something. The owner is doing five things at once. Weighing rice for one customer, answering "are you open on Sunday?" from another on the phone, mentally tracking that Ramesh still owes ₹200 from last week, and somewhere in there, trying to remember if they need to reorder sugar.

None of this is written down anywhere useful. It's all in the owner's head, or scrawled in a notebook that only makes sense to them. And every interruption — every phone call asking something they could answer themselves if only someone had told them — costs the owner time they don't have.

That's the actual problem. Not "shops need an app." Shops need someone to take fifteen small burdens off their hands, without asking them to learn anything new. And for a business built entirely on conversation — haggling, remembering, answering — the only interface that actually fits is the one they already use all day: talking.

Why voice, not another app

I considered building this as a typical dashboard-and-form product first, and quickly realized that's exactly the kind of tool a busy shop owner won't use. They don't have time to open an app, tap through menus, and type "sold 5kg rice" into a form while a customer is standing in front of them. But they can say it, the same way they'd tell an assistant standing next to them.

So the shape of the solution followed from the shape of the problem: a voice agent that behaves less like software and more like a second person in the shop — one who remembers things, doesn't get tired, and knows exactly when to say "I can't decide that, let me get the owner."

I named it Dukaan Mitra — shop friend.

Building the actual assistant

The underlying machinery is the same as any voice pipeline: speech-to-text listens, an LLM decides what to say, text-to-speech (I used Murf Falcon, which turned out to matter more than I expected — a slow voice makes a conversation feel like talking to a machine, a fast one makes it feel like talking to a person) speaks back, and a real-time transport layer (LiveKit) carries all of it.

This diagram illustrates the real-time voice pipeline of the LiveKit Agent, showing how a caller’s audio flows through VAD, Deepgram STT, Gemini LLM, and Murf Falcon TTS before being delivered back as natural speech via RTP/WebRTC. It also highlights low-latency streaming, context-aware responses, and interruption handling.

But the pipeline was the easy part. The interesting decisions were all about judgment:

What should it never do on its own? Confirm a discount the owner never agreed to. State a profit number to a stranger. Promise a delivery time nobody set. These aren't technical constraints — they're the same boundaries you'd expect from a trustworthy employee.

What should it remember, and when should it ask first? A returning customer shouldn't have to explain themselves twice — but the agent also shouldn't silently store personal details without asking. So it asks: "is it okay if I remember this for next time?" And if the answer is no, it forgets.

When should it stop and get a human? A customer disputing a charge, or asking for a refund, isn't something an AI should quietly resolve on its own authority. So instead of guessing, the agent explains what it wants to hand off, asks permission, and creates a real request with a reference number — the same way you'd expect a competent employee to escalate something above their pay grade rather than improvise.

When should it call someone unprompted? If stock for an item is running low, waiting for the owner to notice is a missed reorder. So the agent can place an actual outbound call — but it opens carefully, because unlike an inbound call, the person on the other end didn't ask for this conversation. The first two sentences say who's calling, why, and how to make it stop.

What this actually is, in the end

Not a chatbot with a shop theme bolted on. A system that tries to behave the way a good employee would: confident about what it knows, honest about what it doesn't, careful about what it shares, and willing to say "let me get someone" instead of guessing.

The gap between "an AI that can talk" and "an AI you'd actually trust to answer your shop's phone" turned out to be almost entirely about restraint — not capability.

For anyone building something similar

If you're building a voice agent of your own, the shape is roughly:

  • STT + LLM + TTS + real-time transport as your core pipeline — LiveKit, Deepgram, Gemini, and Murf Falcon worked well together here
  • A small database for memory, not a full backend — SQLite was more than enough
  • Write your agent's limits before its features. What it should never claim, never decide, never share — that's the part that actually earns trust
  • Test the failure path as seriously as the success path — that's where the real bugs hide

Code is here if you want to look under the hood: github.com/coderkartik7/murf-livekit-starter

Built as part of 10 Days of Voice Agents — VoiceForBharat Edition by Murf AI, powered by Murf Falcon.

Top comments (0)