Hi DEV — I’m Nikita, founder and engineer at SkipCalls. I’m building it with a two-person founding team because small businesses lose real revenue every time a customer call goes unanswered.
SkipCalls is an AI phone receptionist that answers incoming calls, qualifies leads, takes structured messages, books appointments, transfers calls when needed, and sends the owner a clean summary afterward. It can also make outbound calls for follow-ups and campaigns.
This is my first post here, so I wanted to introduce both the product and some of the engineering lessons behind it.
The problem we chose
A missed website chat can wait. A missed phone call often cannot.
For a plumber, law office, electrician, realtor, salon, or medical office, the person calling may simply move to the next business if nobody answers. Traditional voicemail records the problem but does not solve it. The caller still has to explain everything, wait, and hope someone calls back.
We wanted the phone experience to feel closer to a capable front-desk teammate: available 24/7, able to ask useful follow-up questions, aware of the business, and honest about what it can and cannot do.
What happens during a call
A typical inbound flow looks like this:
- A customer calls the business’s existing number.
- The unanswered or after-hours call forwards to the SkipCalls number.
- The AI receptionist answers with the business’s greeting and context.
- It handles the conversation, collects the details the owner actually needs, and can book or transfer when configured.
- The owner receives the transcript, summary, and next actions immediately.
The setup is intentionally simple. A business owner should not need to understand SIP, realtime audio, prompt design, or webhook infrastructure to stop missing leads.
The stack behind it
I’m the solo engineer on the founding team, so the system has to stay understandable while covering several very different surfaces:
- TypeScript and NestJS for the backend and product APIs
- Python for the realtime voice agent
- React and React Native for the web and mobile apps
- LiveKit for realtime voice infrastructure
- PostgreSQL and Redis for durable state, queues, limits, and coordination
- Webhooks and calendar integrations for the actions that happen after a call
The hard part is not making a model say words over a phone connection. The hard part is making the whole system dependable when the caller interrupts, changes direction, has background noise, asks for something the business never configured, or needs a real person.
Lessons from building production voice AI
1. Latency is part of the personality
A correct answer that arrives too late feels broken. Voice agents need fast turn detection, careful streaming, and interruption handling. Small delays that are invisible in chat become uncomfortable silence on a call.
2. Business facts matter more than generic cleverness
The best prompt cannot invent opening hours, service areas, pricing rules, or transfer policies. We treat the business profile and explicit owner configuration as first-class product data so the receptionist can be useful without guessing.
3. Failure modes must be designed, not hidden
Calls can fail at the carrier, SIP, realtime session, model, tool, queue, or downstream API layer. A production system needs observable handoffs and safe fallbacks. “The model usually handles it” is not an operations strategy.
4. The after-call workflow is half the product
A natural conversation is valuable, but the business outcome matters more. Did we capture the caller’s name and urgency? Was the appointment created? Did the owner get a concise summary? Can a CRM or automation continue the workflow? We design from that outcome backward.
5. The AI should know when to hand off
A receptionist earns trust by staying within its role. Transfer rules, callback paths, explicit confirmations, and transparent limitations are as important as speech quality.
What we are building toward
Our goal is straightforward: give small businesses a phone receptionist they can set up in minutes and confidently leave running. That means better reliability, deeper scheduling and CRM workflows, clearer controls for business owners, and tools that make every call actionable.
You can see the product at skipcalls.com.
I’d love to hear from other builders working on voice AI, realtime agents, telephony, or small-business automation. What failure mode surprised you most when you moved an agent from a demo into production?
Top comments (1)
The failure mode I keep hearing about from builders once they're past demo: multi-tenant data leaking between businesses on the same Postgres tables, because a query scopes correctly when there's only one business's rows in a dev database. How are you isolating each business's calls and transcripts from every other business's on the Postgres side, row-level policies or checked in the NestJS layer?