How can you build something prod ready between patient appointments?
Dr. Erfan Zarger runs a full-time dental practice at Potomac Dental seeing patients all day, and building in the gaps. He spent nearly 15 years writing software before ever picking up a dental drill, and now runs a thriving practice in North Bethesda, Maryland offering everything from cosmetic veneers to implants to root canals.
And he still shipped a bilingual AI receptionist in 2 weeks.
When Dr. Zarger took over his practice, the issue was obvious. Calls were being missed.
Mostly after hours, when patients were calling with real intent and no one was there to answer.
“Almost 90% of after-hours callers don’t even pick up when you call them back the next morning.”
At the same time, he lost his Spanish-speaking front desk staff member. Replacing that role didn’t make sense for the volume, but the need didn’t go away.
So now the system had to do two things without adding staff.
- Capture every after-hours call
- Support both English and Spanish patients
Dr. Zarger knew he needed a bi-lingual AI receptionist. If you’ve tried to build anything like this, you already know where it breaks.
Not in the model. Not in the call flow.
In the integration layer.
You can get a request working pretty quickly. That’s not the issue.
The issue is everything after that:
- inconsistent data across systems
- scheduling logic that doesn’t behave the same way twice
- endpoints that technically work but don’t map cleanly to real workflows
- edge cases that multiply the second you hit production
- legacy PMS with an update that throws everything off
And this is exactly what Dr. Zarger ran into trying to connect his voice layer to his practice management system.
Instead of continuing to wire directly into his PMS, he changed the approach.
He stopped trying to solve integration as part of the product. When searching for a solution in Google Gemini and ChatGPT he had the same answer: Synchronizer API by NexHealth.
Dr. Zarger had his system up and running in one day.
Using the Synchronizer API gave him a stable, consistent way to access scheduling and patient data without rebuilding logic for every system or edge case.
The part that stood out wasn’t just the API.
It was his developer experience with access to:
- clean, organized documentation
- multi-language code samples
- a live sandbox where he could test calls before touching production
If you’ve been stuck in integration work, this is the point where most projects either accelerate or stall completely.
If you want to see what that actually looks like, the docs he used are here: [https://docs.nexhealth.com/]
Within two weeks, the system was live. Not only that, it was built in the gaps between running a dental practice.
Dr. Zarger deployed two AI receptionists.
The first handled after-hours English calls. It answered every call, collected patient details, answered common questions, and surfaced appointment availability without needing staff involvement.
The second handled Spanish-language calls at any hour, translated the full conversation into English, and sent structured summaries to the front desk.
So when staff came in the next morning, they weren’t guessing what happened. They were following up with clarity.
“Even if both of my front desk staff don’t show up to work, the AI can answer all the phone calls with no problems.”
That’s not just automation.
That’s removing a failure point from the system.
In two weeks:
- zero after-hours missed calls
- two AI receptionists running simultaneously
- bilingual coverage without hiring
- staff time shifted from triage to actual patient work
This wasn’t a prototype.
It was running in production.
He wasn’t working full days on this. He was building between patients.
If you’re building anything that touches real-world systems, this is the constraint: You don’t lose time building features.
You lose time trying to normalize everything around them.
The developers who ship aren’t the ones who solve every layer. They’re the ones who decide which layers not to own.
Dr. Zarger made that decision early. That’s why this took two weeks instead of two months.
https://synchronizer.io/case-studies/dr-zarger
https://postman.com/nexhealth/nexhealth-public
https://github.com/synchronizer-api
Top comments (0)