Case study · YM's own product
Vetfaz: designing software for a business full of rules.
A veterinary clinic is several businesses in one: scheduling, appointments, 24-hour hospitalization, shifts paid differently for each professional, and finance, sometimes across more than one location. Vetfaz is the veterinary clinic management system YM is building, still pre-launch. Here are the decisions behind it and how it gets built. If your company also juggles locations, roles and money rules, the same thinking applies.
Why clinic software is hard to get right.
The hard part lives in the business rules. Each rule below became an architecture decision before the first screen was built.
Many clinics, one system
Each clinic must see only its own data, even though they all live in the same system.
DecisionEvery record belongs to a clinic, and every action checks on the server who is asking and for which clinic. The system never trusts what comes from the browser.
People in more than one place
The same vet works at two clinics, with a different role at each.
DecisionOne account per person, linked to each clinic separately. The system won't book the same person at the same time in two clinics, and the other clinic only sees "Unavailable".
Each role sees its own slice
Owner, front desk, nursing and finance need different screens and limits.
DecisionNine roles with their own permissions. The menu only hides options; the real permission is checked inside every action.
Money split by rules
Each professional is paid differently: per appointment, per shift, by percentage.
DecisionPayouts are modeled as data rules, not code written for each clinic. When a new way to pay fits the model, it becomes a new setting, with no code change.
The architecture that holds up as the business grows.
Decisions that apply to any business with several locations, several roles and money rules.
Automation that never doubles up
What the system records on its own from a closed appointment never happens twice, not even with a double click or two triggers at once.
Fixed rules where predictability matters
Shift suggestions follow rules, not AI: the same input always gives the same schedule. It starts as a draft, never breaks a mandatory rule and can be undone.
A name on every change
Changes keep who made them, in which clinic and what changed. In the shift schedule, the owner will see who logged each hospitalized patient's progress and spot a name that doesn't match before closing payouts.
Modules switched on per clinic
Hospitalization and shift scheduling are modules each clinic will turn on when it needs them. Switched off, they leave the menu and the system refuses any of their actions, even from outside the screen.
The customer's customer
The clinic pays, but pet owners will use the system too: they'll come in through a link the clinic sends them, with no account, to book and cancel.
Routines that survive failure
Reminders run on a routine that never sends the same message twice, and one failed send doesn't take down the rest.
The AI drafts. A person decides what goes.
One door for the AI
All AI in the system goes through one side panel, and screens only hand over context. If a better AI comes along, it's swapped in one place, with no screen rebuilt.
Nothing counts until it's reviewed
During appointments, anything the AI writes will come in as a draft and only counts once the vet has reviewed it. The AI supports; the vet decides.
Actions only with approval
The AI will propose the action already filled in, and nothing will be saved without the user's click. It will only be able to do what that person's role allows.
Numbers calculated, not made up
Management numbers will be calculated by the system. The AI will get the finished number, explain it and show where it came from.
Want to know more about the product? Vetfaz has its own site, with the launch waitlist.
A process that catches bugs before they reach a user.
It's the same way we'd build your company's system.
- access roles, each tested against what it can't do
- 9
- minimum share of changed code covered by tests before release
- 85%
- real clinic records used in testing
- 0
- A spec before the codeEvery feature starts with a short spec: what it does, for whom, what's left out and how we'll know it's done. It's approved before the first line is written.
- Work grouped by areaWork is grouped by area of the system: each screen is opened once and finished whole, and two tracks move at the same time without undoing each other.
- A test for every fixNo fix is closed without a test that would fail if it were undone. On every change, tests check that one clinic can't see another and that no role does what it isn't allowed to.
- Review before releaseBefore each version goes live, the system is reviewed profile by profile, following a script, in a test version. If any test fails, the release stops on its own.
The same thinking, in your company's system.
Every system gets the architecture its problem calls for. What carries over is the way of thinking:
Vetfaz shows how we work. It isn't a client result yet.
- Several locations and rolesBranches, roles and permissions designed before the screens, so the system grows without turning into patchwork.
- Business rules as dataWhat changes often, like commissions, prices and deadlines, becomes a setting. Adjusting a rule doesn't turn into a new project.
- AI with approvalAI takes on the repetitive work, and decisions stay with your team. When AI isn't the right answer, we'll tell you.
What people ask about this case.
No. It's YM's own product, still pre-launch. Anything this page describes in the future tense doesn't exist yet.
Because your own product tests the method against real business rules, end to end. What works there carries over to client projects.
Not necessarily. The architecture comes from each company's problem. What applies to every project is the process: a spec before the code, permissions checked on every action, a test for every fix and review before release.
Every record belongs to one clinic, and every action checks on the server who is asking and for which clinic before reading or saving anything. The system never trusts what the browser sends, and tests check on every change that one clinic can't see another. The same design works for any multi-tenant software serving many companies from one database.
At vetfaz.com.br (in Portuguese), where the launch waitlist lives. The "Visit Vetfaz" button at the top of this page takes you there.
Got a process no off-the-shelf software can handle?
Tell us about it. We'll reply with the next step, even if that step isn't with us.
Prefer to write? We'll reply with a clear next step.
A few lines are enough: the store that gets traffic but doesn't sell, the process your team still does by hand, the number nobody can explain. We read every message carefully.
Taking on new projects
If we're not the right fit, we'll tell you.
Or email contato@ygormendanha.com