Does Velarya Replace Your EMR? The Three Ways Clinics Actually Run It

Velarya is a full EMR, and you do not have to switch to it to use Velarya. Clinics run it three ways: as the whole system, as the front of the clinic with charting left where it is, or as the patient app on its own. The one rule that holds in all three is that only one calendar can take bookings.

This question comes up on almost every call, usually in the same shape. The owner has spent months configuring Zenoti or Boulevard or Mangomint, her team finally knows where everything is, and she is not doing that again this year. She wants an app with her clinic's name on it. She wants memberships that bill themselves. She does not want a migration. All three of those are available at the same time, and which setup she picks depends on one thing: which system she wants her front desk working in.

Is Velarya a full EMR?

Yes. Charting, intake forms, consent and e-signature, photo documentation with markup, before and after tracking, medical alerts and clinical notes are in Velarya on every plan. There is no clinical add-on to license and no module to unlock. A clinic that runs Velarya as its whole system does not need a second product for the clinical side.

The clinical record is built to be separate from the operational one on purpose. Allergies, medications, conditions and pregnancy status sit in a structured clinical profile that is encrypted and gated by role, so the front desk sees the scheduling note and the injector sees the contraindication. Medical alerts carry a severity, record who created them, and leave a trace when they are removed. Charts can be built from a template or from scratch, and a supervising provider can review and sign off.

So the honest answer to "is this a real EMR or a rewards app with charting bolted on" is that the charting came first and the app sits on top of the same patient record. That is also why the three setups below are possible at all.

The three ways clinics run Velarya

Every clinic on Velarya is running one of these. They differ in one decision: how much of the clinic's day moves into Velarya.

Nothing about starting in one of these makes moving to another harder later. The patient app is the same app in all three, which matters more than it sounds and is covered further down.

Setup one: Velarya runs everything

One system, one patient record, one subscription. The calendar, the charts, the register, memberships, rewards and the app all read and write the same record, so a question that spans two of them has one answer. Whether a member has an unused facial this cycle and a documented allergy is a single lookup at the desk, not a phone call to whoever knows.

This is the setup with the lowest running cost and the highest switching cost. You move your patients, appointments and history across, your team learns one product, and you stop reconciling anything. Data import and 1:1 onboarding come with every plan. We wrote up what actually moves and what somebody carries by hand in how to switch med spa software without losing your client data.

Most clinics get here eventually. Plenty of them do not start here, and that is fine.

Setup two: Velarya runs the front of the clinic, your system keeps the charts

This is the setup people do not know exists, and for a clinic whose only real attachment is to its clinical history, it is usually the right one.

Booking moves to Velarya. Patients book in the app or through the web booking flow, your front desk works the Velarya calendar, and payments, packages, memberships and rewards all run in Velarya. Your current system stays open for one job: writing and holding the charts. Providers open it to document a visit and close it again.

What you get is one calendar, one register, one patient list for everything commercial, and an app under your clinic's name, without touching a single clinical record. What it costs you is that providers work in two windows, and a patient who is new in Velarya has to exist in the other system before anyone can chart on them. That is real, and it is a smaller tax than most owners expect, because it only applies to new patients rather than to every transaction.

This setup only works if you actually move the links. That is the next section, and skipping it is the one way to make a mess.

Setup three: Velarya runs the patient app only

Your current system keeps booking, charting and reminders. Velarya runs the app, loyalty, memberships and shopping, with Velarya booking switched off so no second calendar can exist.

Patients sign in and see a points balance, the challenges you have switched on, and their referral code. They buy a package before they arrive. They join a membership, save a card, and get charged on the cycle you set. Birthday and welcome rewards fire without anyone remembering them. You reach all of them with push, which lands on the home screen with no per message fee.

To book, they do what they already do. They call, or they use the booking page you already run.

Some Velarya features need the Velarya calendar and stay off with it. Priority booking for members. The smart waitlist. Check in rewards. Appointment reminders keep coming from your current system, not from us. Nothing else in the app is affected.

The one rule that makes any of this work: one calendar

Two live booking systems will double book you. That is true of any two booking systems, not a Velarya quirk. So the rule is not "turn Velarya booking off." The rule is that you pick one calendar and then point everything at it.

Whichever you pick, every one of these has to end up at the same place. This is the checklist clinics skip, and then wonder why a stranger booked into a slot that was already taken.

If you are choosing Velarya as your calendar, you get the app, the web booking flow, a front desk view and a calendar view, so there is somewhere for every kind of booking to land. If you are keeping your current calendar, we switch Velarya booking off on your account and the app never offers a time.

Either answer is fine. Half of one and half of the other is the only wrong answer.

What gets entered twice, and what does not

Velarya runs independently of your current system. It reads nothing from it and writes nothing to it, and that separation is exactly what makes running alongside safe: nothing to move, no downtime, no risk to a chart. The practical consequence to plan for is that a small amount of information is entered in both places, and the table below is the complete list.

The pattern is worth naming plainly. The cost of running alongside is administrative. The cost of migrating is clinical. An owner who has just spent a year configuring her system usually knows which of those two she would rather carry, and there is no wrong answer to that.

One exception is coming. From early 2027 a Boulevard clinic will not have this column at all, because the native integration keeps both sides in step. That is covered further down.

What each setup costs

The plan you are on does not change with the setup. Essentials is free and puts your clinic inside the Velarya app, which rebrands itself to your practice, with up to 10 service providers. Signature is $499 a month plus $199 per additional location and publishes your own app in the App Store and Google Play under your clinic's name. Enterprise adds custom domains, SSO and a success manager. Signature carries a one time setup fee that annual billing waives, and every plan is month to month. The full list is on the pricing page.

Two things worth being straight about. Running alongside means paying your current vendor and Velarya at the same time. And every Velarya plan includes charting whether you use it or not, which does not make the plan cheaper. It does mean the clinical side is sitting there ready on the day you want it, which is the whole reason moving later is cheap.

Payments in the app run at Stripe's standard rates with nothing added by us, which is 2.9% + 30¢ for cards on file and online, and 2.7% + 5¢ for cards tapped or inserted in the clinic. If you are curious how that compares across the category, we published every price we could find in the best med spa software in 2026.

What about a native Boulevard integration?

It is in build and ships in early 2027. Boulevard is the first system Velarya will run with rather than beside, and it changes the arithmetic above for Boulevard clinics specifically.

Your team keeps working in Boulevard. Appointments, patient records and purchases stay in step across both sides, so the clinic runs its day from the account it already uses and the Velarya side keeps up on its own. What that removes is the double entry in the table above, which today is the main running cost of the patient app setup.

The effect is that a Boulevard clinic gets most of what the whole system setup gives you without the migration. One patient record in practice. An app under the clinic's name. Memberships and rewards that bill and earn on their own. And a team that never leaves the software it already knows.

Until it lands, and for every other system today, the three setups above are how this works. Velarya runs independently of Zenoti, Mangomint, Aesthetic Record, Pabau and everything else, which is exactly why it does not matter which one you run. The name on your current software has no bearing on any of this. Your calendar and your charts live somewhere else, and that is the only fact these setups depend on.

Moving later, without rebuilding the app

Starting in one setup does not make moving to another harder. Turning the calendar on is a setting, not a rebuild.

The app stays the same app. Same name, same icon, same App Store listing, same Apple Developer account in your clinic's name. Your patients do not download anything new and do not sign up again. Their points, their memberships and everything they have bought stay on the same record, because all of it was in Velarya the whole time. That is the expensive part to redo, and the part you never have to.

Apple requires an app published under your clinic's name to sit in your clinic's own Apple Developer Organization account. You own that account and we publish on your behalf as your authorized agent, so you are never locked out of your own app, in any setup.

Which one should you pick?

Four questions get most clinics to an answer in about a minute.

Is your current contract ending in the next few months? Then run the whole thing on Velarya. Paying two vendors to avoid a migration you are about to be free to do anyway is the expensive choice.

Are the charts the only thing keeping you where you are? Then move the front of the clinic and leave the charts. You get one calendar, one register and the app, and no clinical record moves.

Did you finish configuring your current system this year? Then take the patient app on its own. It is the smallest change available and it is the one that pays fastest, because memberships and rewards start earning the week they switch on.

Are you on Boulevard? Then take the patient app now and let the integration pick it up in early 2027, at which point your team runs everything from the Boulevard account it already uses and nothing is entered twice. Every membership, points balance and app install you build in the meantime carries straight through.

Common questions

Do I have to migrate my data to use Velarya?

No. In the front of the clinic and patient app setups, nothing is exported and nothing is imported. Your clinical records stay where they are and your providers keep charting where they chart today. Migration only happens if you decide to run Velarya as your whole system, and then the import and onboarding are included in the plan.

Can I use Velarya for booking and keep another system for charting?

Yes, and it is a common setup. Patients book in the app or through the web booking flow, your front desk works the Velarya calendar, and payments, memberships and rewards run in Velarya. Your current system stays open for charting only. The requirement is that every booking link you own points at Velarya, so only one calendar is taking appointments.

Does Velarya work with Zenoti, Mangomint, Aesthetic Record or Pabau?

Velarya runs beside all of them, in the sense that it does not read them, write to them or ask them for anything. That is why the answer is the same regardless of which one you have, and why nothing needs to be arranged with your current vendor before you start. Boulevard is the exception, from early 2027.

Does Velarya integrate with Boulevard?

A native Boulevard integration ships in early 2027, and it is the first one Velarya is building. Both sides stay in step, so a Boulevard clinic keeps running its day from the Boulevard account it already uses while Velarya runs the branded app, memberships, rewards and in-app purchases on top. Until it ships, Boulevard clinics run one of the three setups above like everyone else.

What can the app do if Velarya booking is switched off?

Everything that is not the calendar. Patients earn and redeem points, complete challenges, share referral codes, buy packages and services, join and manage memberships, save a card, and receive push notifications. Welcome and birthday rewards still fire on their own. Priority booking, the smart waitlist and check in rewards need the Velarya calendar, so they stay off with it.

Will I end up with two calendars?

Only if you point booking links at both systems. Pick one calendar, move every link to it, and switch booking off in the other. When Velarya is not your calendar we switch its booking off at the account level, so the app cannot offer a time and no appointment can be created there.

Is Velarya HIPAA compliant?

Yes. Clinical information is stored encrypted and access is gated by role, so operational staff see what they need to run the day and clinical detail stays with the people treating the patient. That holds in every setup, including the ones where Velarya is not holding your charts.

Can I start small and move everything over later?

Yes, and it is the most common path. The app, the patient records inside Velarya, the memberships and the points balances all carry forward when you turn booking or charting on. Your patients notice nothing, because the app they already have does not change.

If you want to see any of the three running against what you already have, book a demo and say which system you are on. We will set the call up around that rather than showing you a migration you did not ask for.