Building Voxa, a production-oriented AI receptionist SaaS for local service businesses.
Voxa is an AI receptionist system designed to help barbershops handle inbound calls, understand booking intent, validate business rules, and execute appointment workflows through provider integrations without allowing the LLM to directly mutate external systems.
Overview
The goal was not to build a chatbot. The goal was to design a reliable business workflow: voice input, intent validation, appointment logic, provider execution, and operational proof.
The business problem
Barbershops lose revenue when calls are missed, appointments are unclear, and staff are interrupted during cuts. The product thesis: a focused AI receptionist can handle routine appointment calls while preserving the shop’s existing booking provider and operating rules.
What I built
A multi-component SaaS system with telephony ingress, normalized call events, orchestration workflows, Postgres-backed state, provider-safe worker execution, Square appointment operations, tenant boundaries, operational records, and deployment/lab documentation.
Stack and systems touched
System architecture
Voxa uses a separation-of-responsibility architecture: conversation handling is not allowed to directly write to external providers. Mutations are validated, persisted, executed by a worker, and only marked successful after provider confirmation.
This diagram is intentionally sanitized. Repository code, secrets, provider credentials, and customer data are private.
Engineering decisions
Most of the hard work was not prompt writing. It was reducing ambiguous voice conversations into safe, testable, provider-backed business workflows.
No LLM side effects
The AI can help interpret intent, but it does not directly mutate appointment providers. Provider writes are executed only through controlled worker paths.
DB-first workflow state
Call state and workflow progression are persisted in Postgres so the system can be audited, resumed, debugged, and reasoned about outside the voice session.
Provider confirmation gate
Voxa does not claim success until the external provider confirms the mutation. This avoids false confirmations during failed booking attempts.
Idempotent execution
Worker operations are designed around repeat-safe execution so retries do not create duplicate provider-side side effects.
Tenant-aware boundaries
The architecture treats each shop as a tenant with separate operating rules, provider configuration, and business context.
Operational documentation
I maintained docs, runbooks, implementation records, and readiness notes so the system could be tested, reviewed, and improved without relying on memory.
Evidence of work
The private repository includes implementation history, architecture notes, runbooks, testing records, and deployment/lab documentation. This public page summarizes the work without exposing sensitive internals.
Private code walkthrough, sanitized screenshots, and deeper implementation notes can be shared selectively on request.
Why this work matters
For software/product teams
Voxa demonstrates practical ownership across product, backend workflows, database-backed state, external APIs, deployment concerns, and operational debugging. It reflects the type of work required in small, high-ownership teams where shipping matters.
For AI-enabled development
I used AI as leverage during the build process, but the engineering work stayed grounded in systems thinking: boundaries, state, retries, provider truth, documentation, and business constraints.
Contact
Samuel Lamarche · Montréal area, Canada · samxlamar@gmail.com · linkedin.com/in/Samuel-Lamarche