Can Vapi be vibe coded?

Build brief — a focused alternative to Vapi

**Verdict:** Partly, if you narrow it · **Buildability:** 53/100 · **Category:** Dev Tools

**Source:** https://www.canitbevibecoded.com/vapi

Independent editorial assessment from Can It Be Vibe Coded? Not affiliated with, endorsed by, or derived from Vapi. Verify current pricing and capabilities before acting.

Context

**Vapi** — API-first platform for inbound and outbound phone and web voice agents. It currently costs Variable pricing.

A focused inbound agent is a credible contained build with LiveKit Agents or Pipecat. Replacing Vapi as a product is much larger: it combines realtime orchestration, provider abstraction, phone-number and SIP workflows, outbound campaigns, tool calls, testing, observability, scaling, support, and compliance options. Self-hosting can remove Vapi's $0.05 per-minute platform fee, but model, carrier, number, infrastructure, failed-call, monitoring, and engineering costs remain.

This brief describes a focused, single-operator replacement for the part of Vapi that is genuinely reproducible. It is deliberately narrower than the product it replaces, and it says so in writing. Build the useful core; do not pretend to have rebuilt the rest.

What you are building

Route a SIP trunk into a realtime agent, stream speech through STT, LLM, and TTS with interruption handling, run a server-side tool, and save the call outcome.

Build the focused developer workflow you use repeatedly, with local configuration.

A responsive interface with real empty, loading, success, and error states.

Requirements

Functional

Public Linux VM, domain, TLS, and correctly restricted SIP, WebRTC, and RTP ports.

SIP trunk and phone number from a carrier such as Telnyx.

Country-specific consent, recording, caller-ID, and outbound-calling review before real traffic.

Data and integrations

STT, LLM, and TTS provider API keys.

Each of these needs a real account, credential, or quota. Set them up before writing feature code.

Non-functional

Accessibility: semantic markup, labelled controls, visible focus, and reduced-motion support.

Security: server-side secrets, validated input, and no credentials in the client bundle.

Reliability: retries with backoff on external calls, and a clear failure state when a provider is down.

Portability: the operator can export their data and leave without losing it.

Implementation brief

Build me a focused, self-hosted alternative to Vapi for one inbound support number.

Requirements:

Use Python 3.12 and livekit-agents~=1.5 with one named AgentServer worker.

Use direct provider plugins, not LiveKit Inference or another managed agent host.

Run LiveKit Server, Redis, and LiveKit SIP with Docker Compose on one Ubuntu VM.

Put Caddy in front of HTTPS/WSS; expose only the documented SIP and UDP media ports.

Provision one Telnyx DID and credential-authenticated SIP trunk. Include checked-in

LiveKit inbound-trunk and dispatch-rule JSON that sends calls to support-agent.

Build an AgentSession with Silero VAD, Deepgram Nova-3 STT, gpt-5-mini through

the OpenAI plugin, and Cartesia Sonic-3 TTS. Load every secret from .env.

Give the agent one narrow support prompt, interruption handling, and two tools:

look up an order in SQLite and save a callback request after caller confirmation.

Persist call id, timestamps, transcript, tool results, and outcome to SQLite.

Add structured JSON logs and /healthz; recording is off by default.

Include unit tests for both tools and scripted agent tests for lookup, refusal to

invent an order, callback confirmation, and a caller interruption.

Provide make setup, make dev, make smoke, and docker compose up -d commands.

The smoke test must work in the LiveKit agent console before a real PSTN call.

README: DNS, TLS, firewall, Telnyx, trunk, dispatch, provider-key, and test-call

steps, plus common one-way-audio and SIP authentication checks.

The cost section must say the Vapi fee is removed, while the DID, SIP minutes,

model usage, VM, failed calls, monitoring, and operator time remain. Link the

source-backed calculator at https://voice.oss.codes for changing rates.

Out of scope: outbound campaigns, a multi-tenant dashboard, squads, billing,

automatic provider failover, call recording, compliance claims, and high availability.

Delivery standard

Inspect the repository first, then write a short implementation plan before writing code.

Deliver the smallest complete end-to-end workflow first; every primary control must work against persisted data.

Use real validation and storage; never substitute fake dashboards, decorative controls, hard-coded success states, or mock integrations.

Include responsive layouts plus genuine empty, loading, success, validation, and failure states.

Keep secrets server-side in environment variables, provide .env.example, and never commit credentials or user data.

Add structured logs around every external call and return actionable errors without leaking sensitive details.

Write unit tests for the core logic and one automated test of the main user journey.

Finish with a README covering setup, architecture, data location, backups, tests, deployment, and known limitations.

Acceptance criteria

A clean install starts the app using only the README and .env.example.

The primary journey works from first visit through saved result, reload, edit, export, and deletion where applicable.

Invalid input, missing configuration, provider failure, and an empty database each have a usable state.

The interface works at 390px and 1440px, is keyboard navigable, and shows visible focus on every control.

Tests, type checking, linting, and a production build all pass with no ignored failures.

No part of the interface implies a live integration, security guarantee, or scale capability that was not actually built and verified.

Non-goals

Do not build these, and do not claim to have replaced them:

Managed realtime infrastructure, scaling, provider failover, and support.

Assistant, squad, workflow, phone-number, and provider configuration APIs.

Outbound campaigns, carrier integrations, spam mitigation, and production telephony debugging.

Hosted simulations, evaluations, call logs, recordings, analytics, and retention controls.

Reliability at the vendor's scale is an operations problem, not a prompt.

Connectors, OAuth flows, and vendor API changes require constant upkeep.

What you still own after launch

Secure credentials, rotate secrets, and handle provider rate limits.

Run migrations, backups, restores, and dependency updates.

Test the critical journey after every model, API, or hosting change.

Monitor failures and fix the edge cases a first prompt will miss.

Maintain every third-party integration as APIs and OAuth rules change.

Risk

**Operational risk.** The code is achievable; dependable data, integrations, and ongoing operations are the real cost.

Editorial confidence in this assessment: high. No independent one-shot implementation is linked yet.

Prior art

Working open-source software you can read, fork, or borrow from before starting:

[LiveKit Agents + SIP](https://github.com/livekit/agents) — Apache-2.0 realtime agent framework. Pair it with the separately deployed LiveKit Server and SIP service for a self-hosted phone stack

[Pipecat](https://github.com/pipecat-ai/pipecat) — BSD-2-Clause Python framework with composable voice pipelines and broad model, transport, and telephony integrations. You still own deployment and carrier operations

[Voice OSS cost planner](https://github.com/oss-codes/voice-cost) — Source-linked calculator and deployment reference for platform, model, SIP, number, infrastructure, and operational costs. It is a planning companion, not an agent runtime

Generated by [Can It Be Vibe Coded?](https://www.canitbevibecoded.com) · Full report: https://www.canitbevibecoded.com/vapi