Independent product · case study
ZëriMed
AI receptionist and patient communication platform for Albanian clinics.
A full-stack SaaS product exploring how conversational AI, voice infrastructure, and clinic software can work together to handle patient communication and appointment workflows.
- Role
- Founder / Full-Stack Engineer / Product Designer
- Category
- AI / SaaS / Healthcare software
- Platform
- Web + voice
- Status
- In active development
Today
Clinic overview
12
Appointments
08
Handled calls
142
Patients
Today's timetable
Interface reconstruction based on the implemented clinic dashboard; values are illustrative, not usage metrics.
Reception does not scale with patient demand.
Clinics miss patient opportunities when staff are already with a patient, handling another call, or away from the desk. ZëriMed tests a focused idea: make AI the first communication layer for routine requests, while keeping clinic staff in control.
Competing calls
A receptionist can only handle one live conversation at a time.
After hours
Patient requests continue when the clinic desk is closed.
Repeated questions
Hours, location, services, and preparation create constant interruptions.
Missed intent
A missed call often hides a booking, change, or urgent request.
02 / System architecture
More than a chatbot
A useful receptionist has to coordinate the phone network, live audio, speech services, model output, clinic context, appointment rules, persistence, and a spoken response as one controlled workflow.
Live call path
Carrier event to validated response
01
Patient
Inbound Albanian phone call
02
Telnyx
Voice API v2 + signed webhooks
03
Media stream
Bidirectional PCMU audio over WSS
04
Soniox
Real-time Albanian STT + TTS
05
AI intent
Structured, allow-listed actions
06
Clinic logic
Context, availability, validation
07
PostgreSQL
Calls, patients, appointments, audit
08
Response
Confirmed action + generated speech
Untrusted input
Caller audio + provider events
Trust boundary
Schema + auth + business validation
Controlled output
Allowed action + spoken response
The web application owns clinic workflows and REST APIs. A separate Node/Express WebSocket service handles long-lived audio sessions. Shared Zod schemas and workspace packages keep provider events, intent objects, and domain data typed across the boundary.
03 / Engineering challenges
The hard parts are between the services
The model is one component. Most of the engineering work is controlling what reaches it, what it may propose, and what the rest of the system does when a dependency is slow, repeated, or unavailable.
Real-time systems
Voice is a timing problem
A phone assistant has to move audio through carrier, speech, reasoning, and synthesis layers without losing call state. Streaming, silence limits, retries, and interruption boundaries matter as much as the model response.
Language
Albanian changes the evaluation
Speech quality cannot be assumed from English benchmarks. The pipeline uses Soniox's Albanian speech support, while scenario-based testing separates transport quality from conversational quality.
Trust boundary
The model proposes; the backend decides
The LLM reduces conversation into a strict intent. It cannot write directly to the database. Clinic, doctor, time, availability, call state, and explicit DTMF confirmation are validated by trusted application code.
Reliability
External events arrive more than once
Signed Telnyx webhooks are deduplicated and call-control commands use stable identifiers. Readiness checks distinguish a running process from a voice path that is actually safe to route traffic through.
Data boundaries
Healthcare context requires restraint
Tenant isolation, encrypted transcripts and notes, bounded retention, redacted observability, role checks, and staff escalation shape the architecture. The product does not claim autonomous medical advice or certification.
04 / My contribution
What I worked on
I am building the product across strategy, interface, application code, AI integration, voice infrastructure, deployment, and testing. The stack is grouped by responsibility—not presented as a logo wall.
Frontend engineering
- Next.js App Router
- React + TypeScript
- Responsive dashboard UX
- TanStack Query and Table
- Zustand state
- Accessible component patterns
Backend engineering
- REST API design
- Prisma data modeling
- PostgreSQL workflows
- Clerk authentication
- Tenant-scoped authorization
- Idempotent webhooks
AI + voice
- OpenAI structured outputs
- Conversational intent design
- Telnyx Voice API v2
- WebSocket media streaming
- Soniox Albanian STT/TTS
- DTMF confirmation boundaries
Infrastructure + quality
- Railway services
- Docker + Turborepo
- Redis rate limiting
- Sentry observability
- Vitest + Playwright
- Readiness and release gates
Product + UX
- Product discovery
- Clinic workflow mapping
- Information architecture
- Voice-first scope control
- Pilot economics
- Conversion-focused landing UX
05 / Product interface
One operating view around every call
The dashboard is not decoration around the agent. It gives clinic staff the context and controls needed before, during, and after patient communication.
Communication
Receptionist calls
Appointment booked
Incoming call
FAQ answered
Incoming call
Sent to staff
Incoming call
Appointment changed
Incoming call
Consent-gated transcript
Call context is available to authorized clinic staff.
Turn a conversation into an operational result.
Staff need the call outcome, appointment link, consent state, and transcript context—not a raw stream of AI output. The interface organizes the result around the clinic's next action.
Today
Clinic overview
12
Appointments
08
Handled calls
142
Patients
Today's timetable
Connect calls to the working day.
Appointments, patients, calls, billing allowances, messages, and settings share one information architecture. Role-aware navigation keeps owner, admin, doctor, and receptionist responsibilities explicit.
UI reconstructions based on implemented product surfaces; displayed values are illustrative.
06 / Domain model
Clinic data has relationships, not just screens
The schema is designed around tenant ownership, patient context, call state, appointment integrity, and distinct access boundaries for receptionist transcripts and clinician notes.
01
Clinic
owns configuration and access
02
Membership
connects staff roles to a clinic
03
Patient
anchors calls, appointments, and notes
04
Call
records provider state, consent, and outcome
05
Appointment
enforces availability and confirmation
06
Transcript
stores consent-gated receptionist context
07
Patient note
remains clinician-authored and encrypted
Telephony case study
Why the provider decision changed
The early architecture evaluated Twilio-style provider paths. The product standardized on Telnyx because Albanian inbound-number support is a core business requirement and maintaining multiple active protocols increased lifecycle and security risk.
The decision changed more than an API client. It established one signed webhook contract, explicit call identifiers, idempotent call-control commands, PCMU media validation, provider-neutral persistence fields, and a release gate for real Albania-number evidence.
07 / Product iteration
The architecture followed the learning
The work moved from a broad clinic-software idea toward a controlled voice-first pilot. Each phase narrowed uncertainty or strengthened an operational boundary.
01
Problem hypothesis
Map missed calls and repetitive reception work.
02
Product prototype
Shape patient, appointment, call, and clinic workflows.
03
Voice experiment
Connect streaming speech and conversational logic.
04
Provider decision
Standardize the runtime on Telnyx for Albanian telephony.
05
Safety boundaries
Add consent, tenant isolation, encryption, and trusted confirmation.
06
Pilot hardening
Bound usage, expose readiness, and prepare production-shaped evidence.
08 / Decisions and tradeoffs
Technical decisions
The useful story is not that a technology was used. It is why it earned a place in the system and what complexity came with it.
01
Telnyx as the only active telephony provider
- Why
- The product needs an Albanian inbound number, and one canonical Voice API reduces lifecycle and security ambiguity.
- Tradeoff
- Provider-specific webhook, call-control, and media contracts need dedicated adapters and staging evidence.
02
A separate WebSocket voice service
- Why
- Long-lived, bidirectional audio does not fit the same runtime shape as dashboard pages and REST routes.
- Tradeoff
- The web and voice services need shared types, signed stream handoff, independent readiness, and coordinated deployment.
03
Relational, tenant-scoped data
- Why
- Clinics, staff, patients, calls, appointments, usage, and permissions have explicit relationships and transactional constraints.
- Tradeoff
- Every service method must preserve tenant context; convenience queries cannot bypass authorization boundaries.
04
Voice-first product boundary
- Why
- Proving one receptionist workflow is more valuable than launching loosely connected AI features.
- Tradeoff
- Consultation transcription and AI-generated clinical notes were removed; SMS remains transactional and gated.
09 / Engineering signal
What this project demonstrates
ZëriMed is where I practice product and engineering as one discipline: define the useful outcome, design the interaction, build the system, and make its limits visible.
Building beyond CRUD
The product combines real-time audio, async provider events, transactional workflows, and a multi-tenant interface.
Designing explicit boundaries
Untrusted AI output stops at typed proposals; trusted services own validation and mutation.
Operating multiple systems
Web, WebSocket, database, Redis, identity, speech, telephony, and observability have separate failure modes.
Shipping with restraint
Scope decisions remove risky features when they do not help prove the core patient-to-clinic workflow.
Currently building—and proving.
The codebase is substantial, but I do not treat implementation as evidence that every external production dependency is ready.
Product and safety foundations
ImplementedClinic dashboard, patient and appointment workflows, signed Telnyx transport, Albanian STT/TTS integration, structured intent handling, usage controls, and clinician-authored notes exist in the codebase.
Production voice path
Verification requiredAlbanian number provisioning and a credentialed end-to-end staging call remain release gates. A successful build alone is not treated as production proof.
Transactional messaging
Feature-gatedTelnyx SMS foundations exist behind disabled clinic flags. Live Albanian number capability and provider reconciliation still need proof; messaging does not block voice.
Paid pilot learning
NextThe next product work is voice quality evaluation, clinic onboarding, operational reliability, and a deliberately small early-access pilot.
Verified stack