ABOUT · SINCE 2001

A schema refined over 25 years, shipped as software in 2024.

EXmedic began as an internal billing system for a four-physician practice that couldn't find a PM + EMR that actually worked. We rebuilt the UI, kept the data model, and made it into a product other small practices could run.

Why we're doing this.

Small US medical practices are stuck between two bad options: a cloud PM + EMR that charges per-seat, per-claim, and keeps your data hostage behind a proprietary export; or a billing service that takes a percentage of every dollar you collect and leaves you with read-only reports.

We believe a practice should own its software, own its data, and pay a flat price that doesn't scale with success. The tech to make that possible — Postgres, TypeScript, React, a machine in a closet — has been mature for a decade. The product hadn't been built.

So we built it. Not from scratch — from a working system we'd been refining since the year the HIPAA Privacy Rule was published. EXmedic is what 25 years of "one more 837 rejection we can't figure out" looks like when you stop patching and start shipping.

Founded
2001
As an internal billing system.
Shipped
2024
As a product for other practices.
Core tables
135
One schema. One audit log.
Install base
Small
Growing carefully. On purpose.
HISTORY

The long version, briefly.

2001
First line of SQL.
A four-physician practice in Austin hires a developer to replace the paper superbill system. The first claims table has nine columns. HIPAA Privacy Rule takes effect the same year.
2005
First 837 submitted.
Medicare requires electronic claims. The in-house system gains an X12 4010 builder, hand-coded against the implementation guide.
2012
X12 5010, ICD-10, HIPAA Omnibus.
Three mandates in three years. The system survives because the schema was never tied to a specific code set — codes are rows, not columns.
2018
Rebuild, same model.
Migration from a legacy stack to Postgres + TypeScript + React. Every table kept its name. The business logic came along unchanged.
2024
Shipped as a product.
After 23 years of running one practice, two other small practices ask if they can use it. We answer yes, carefully. EXmedic becomes a product.
2026
Here.
Growing deliberately. A handful of installs, each one a conversation. We'd rather ship one great deployment than ten mediocre ones.
PRINCIPLES

How we decide, when it's hard.

01

The data model wins ties.

When a UX convenience fights a schema invariant, the schema wins. That's why an "address change" on a patient doesn't silently orphan a claim with the old address — it writes to the audit log and keeps the historical address on the claim that was already submitted.

02

Own your data. Really.

Every install can produce a complete Postgres dump in a command. Every export is in an open format. If you leave EXmedic tomorrow, you leave with everything — not a PDF of your patient list.

03

Readable output.

The 837 we build is text you can read. The audit log is queryable. The schema is documented. We do not believe "the software is too complex for you to understand" is a feature.

04

Sell one thing at a time.

No upsell prompts, no dark patterns, no "upgrade to see this metric." You buy EXmedic, you get EXmedic. Managed hosting is a separate conversation, not a surprise line item.

05

Grow slowly, on purpose.

Every new install gets a real human on the first call and a real human on the install. We would rather turn down ten prospects than do a bad job onboarding one. The roadmap is a function of what existing customers need, not what looks good on a pitch deck.

06

Honest about what we don't do.

We don't do dental, optometry, DME, or hospital settings — yet or ever. We don't do "AI scribe" today. We don't do patient-portal flashiness. If you need those things as table stakes, we'll say so on the call.

WHO BUILDS IT

A small team. On purpose.

The person who wrote the scrubber is the person who picks up the phone. That won't be true forever, but it's true today — and we're going to delay changing it as long as we can.

PLACEHOLDER — PORTRAIT
Founder & CEO
Product · Billing
25 years running billing for the practice EXmedic was built in. Still reviews every scrubber rule that ships.
PLACEHOLDER — PORTRAIT
Co-founder & CTO
Engineering · X12
Wrote the first 837 builder in 2005 and the current one in 2018. Answers the GitHub issues that look like hieroglyphs.
PLACEHOLDER — PORTRAIT
Head of Onboarding
Install · Support
Runs the 4-week 1:1 onboarding. Has migrated practices off Kareo, AdvancedMD, Athena, eCW, and one very old FoxPro system.
We stopped paying a percentage of collections. Our AR got better, not worse.
Office Manager · 6-provider internal medicine practice
ROADMAP · PUBLIC

What we're actually building next.

Updated every quarter. "Planning" doesn't mean "someday" — it means we've committed to scoping and will publish a decision.

Q2 · 2026
Patient statements · batch print & text
Configurable cadence (30 / 60 / 90 day), text-to-pay link, integrated card-on-file via Stripe or Square. Statement template editable.
Shipping
Q2 · 2026
Carrier-specific scrubber packs
Medicare, Aetna, BCBS family — pre-loaded rule packs kept up to date by us. You still edit them; the baseline is maintained.
Building
Q3 · 2026
Real-time eligibility batch
270/271 against tomorrow's schedule, run overnight. Flagged inactive coverage surfaces on the schedule view before the front desk sees the patient.
Building
Q3 · 2026
Sets · sharing & scheduling
Named Sets that email themselves to you every Monday. Share-with-teammate permissions. No more "re-run the Q2 denial report, again."
Planning
Q4 · 2026
Patient portal · minimal
Statements, secure messages, appointment confirmations. Not an app, not a feed. Same data, a view for the patient.
Planning
2027
Second specialty vertical
We'll pick one — current candidates are behavioral health, podiatry, or physical therapy. Decision driven by customer requests, published openly.
Planning

Want to see if this is the right fit for your practice?

45-minute walkthrough. Your data in a sandbox. No AE, no slides.