Synchro or an in-house tool for your FMG schedule.

The three paths, line by line

	Synchro	In-house, built with AI	In-house, handed to a developer
Who writes your scheduling rules	You, in the interface, with onboarding help	You, by describing them to the assistant	You, by explaining them to whoever writes the code
Cost to start	$0, first month free	The assistant subscription and hosting, plus your hours	The quote, plus your hours alongside it
Running cost, 30 users	$300 CAD a month billed annually	Hosting, plus maintenance that lands on someone	Hosting, plus a block of billed hours
Time to a published schedule	The following week, about 45 minutes of setup	A prototype in days, a production tool in months	Months, depending on that person's availability
Physician constraints	Each physician writes their own in plain language, the AI converts them, the physician validates	To be built	To be built
On-call fairness	Weighting per your rules and a running total visible to the team	To be built	To be built
Shared offices and walk-ins	Office assignment and slot distribution among the physicians on site	To be built	To be built
Everything after publication	Withdrawals, replacements, transfers and notifications included	To be built, and it is the bulk of the work	To be built
A rule that exists only at your clinic	What we cover is what the site describes, the rest goes through us	No limit, and this is the main advantage	No limit
Security patches	Applied by us, without you having to ask	Watched for and applied by whoever built it	Per the maintenance contract, if there is one
Where it runs	On our infrastructure, updated and monitored by us	On a host you choose, configure and monitor	Same, and the contract has to say who keeps the credentials
Maintenance	On us	On whoever built it	Taken back in-house or bought back by the hour
When that person leaves the clinic	No effect	The breaking point	The breaking point, absent a handover contract
Privacy impact assessment	Run by the clinic, with a vendor to answer the technical half	Run by the clinic, for the acquisition and for the development	Same, and the contract has to say who carries it
External audited certification	None, and we say so on the Security and compliance page	None	None
What you are left with	A subscription, with CSV and iCal exports at any time	The code and the data	The code and the data, if the contract says so

"To be built" does not mean impossible. It means the line starts empty and fills up with hours. The rest of this page is about estimating how many.

What an in-house tool does better than we do

The barrier really has come down. A coordinator or a physician who has never programmed can now produce a working web app over a few evenings, with a real database and real accounts. Opening this page by pretending otherwise would be dishonest, and you would catch it in the first line.

Fit to your clinic is the advantage that matters most. A product is a long series of compromises with every other customer. Yours has none. The half-day at the satellite site on the second Tuesday of the month, the physician who takes walk-ins only when the resident is there, the rule nobody outside your clinic would recognize: all of it goes in literally, without having to convince a vendor that it deserves a place on a roadmap.

The distance between "we should change that" and "it is changed" shrinks to a conversation with yourself. No ticket, no prioritization, no other customer ahead of you. And you own the result. No renewal, no price increase, no acquisition that reshapes the product, no vendor shutting down.

One last point, and we mean it sincerely. Building a throwaway prototype to understand your own problem is a good way to spend two afternoons. You come out of it knowing what your real constraints are, in what order they contradict each other, and which ones you are willing to break. It makes you a much harder customer afterwards. We would rather talk to that person.

What the first version actually costs

The cost of a scheduling tool is not measured in screens. It is measured by the list of things that have to exist before a coordinator agrees to publish from it. That list is fairly stable from one clinic to the next.

• A data model that holds up: physicians, slots, offices, sites, on-call shifts, absences, constraints, schedule periods.
• Authentication, roles, and an answer to who is allowed to see whose absence.
• Constraint entry, and above all constraint normalization, when 30 physicians each arrive with three or four rules in different shapes.
• The engine that assigns, which is a constraint satisfaction problem and not a loop.
• What happens when no solution satisfies everything, which is the normal situation rather than the exception.
• On-call weighting and a running total per physician.
• Publication, per-person views, notifications, and export to personal calendars.
• Everything after publication: withdrawal, finding an eligible replacement, transfer, approval, propagating the change.
• Backups, and a restore tested at least once.
• A change log, for the day someone disputes an assignment.

The first half of that list comes out fast with an assistant. The second half decides whether the team abandons its Excel file.

Our estimate comes in two tiers, both to be redone with your own numbers.

A simple version takes 60 to 100 hours. It collects availabilities, applies your main rules and produces a draft schedule the coordinator reviews by hand before publishing. No fairness weighting, no replacement handling, no notifications, a single admin role. It is useful, plenty of small teams need nothing more, and it is the tier where building your own holds up best.

A production tool, the kind a 30-person team uses without keeping its Excel file open, runs closer to 300 to 400 hours. The gap between the two tiers is the second half of the list above.

With an AI assistant, those hours are yours or someone else's in the clinic. At $30 an hour loaded for a coordinator, the simple version comes to $1,800 to $3,000 and the production tool to $9,000 to $12,000. If a physician is doing the building, count in clinical half-days not worked instead and run your own math, because the rate is nowhere near the same.

Handed to a contract developer, the same hours bill between $75 and $125 an hour in Quebec depending on the profile. At the middle of that range, the simple version costs $6,000 to $10,000 and the production tool $30,000 to $40,000. Substitute the figure on your own quote, it is the only one that counts. For reference, 30 users on Synchro cost $300 CAD a month billed annually, or $3,600 a year, which is laid out on the Pricing page.

Two qualifiers, cutting both ways. Those hours are not wasted if part of the work serves you regardless: getting your rules straight is useful whatever tool you end up using. And in the other direction, our own product took far more hours than that and keeps taking more every month. We do not say that to discourage anyone, but to give the order of magnitude of the part that does not show up early.

Time to a published schedule

The milestone that counts is not the day the tool displays a schedule. It is the month the coordinator stops maintaining the Excel file alongside it. As long as both are running, the project is not delivered, it is doubled, and it costs more than where you started.

A prototype that displays a calendar takes a few days, and that is real. A tool that produces a plausible schedule takes a few weeks. The gap between that moment and dropping the safety net is where the calendar stretches, for reasons that have nothing to do with how fast code gets written.

What stretches it is the back-and-forth with physicians. It takes three schedule cycles at minimum to know whether the encoded rules match reality, because a misunderstood rule only reveals itself when it produces a schedule someone refuses. In an FMG, a schedule cycle runs four to eight weeks. The calendar is set by the period, not by typing speed, and that is the part an AI assistant does not shorten by a single day.

With Synchro, configuring a team of 30 users takes about 45 minutes, onboarded. The three cycles of adjustment exist on our side too, with the difference that you spend them correcting rules rather than correcting code and rules at the same time.

Where it is going to run

The app has to live somewhere, every day, because a schedule gets checked in the morning before the first slot. In dollars it is not expensive. A small host, a managed database, a domain name and a transactional email service run to a few tens of dollars a month for a 30-person team. An FMG's traffic is nothing to modern infrastructure.

What costs you is the number of moving parts. The TLS certificate renews itself right up until the day it does not. The free tier the prototype ran on eventually sleeps or gets retired. The managed database has an upgrade cycle of its own, with versions that stop being supported. Email needs domain authentication, without which schedule reminders land in physicians' junk folders and nobody tells you.

Two decisions are worth making at the start rather than later. A host that takes backups is not the same thing as a restore you have tested, and the difference surfaces at the worst possible moment. And the hosting region becomes your call, with the consequences described further down under Law 25.

The maintenance tail

Software does not sit still on its own. A dependency to update, an authentication provider changing its rules, a browser dropping support for something, and one morning the reminder emails stop going out with nobody noticing until a physician misses an on-call shift.

An AI assistant helps a great deal with the repair, on one condition: that someone notices the breakage and can describe what is wrong. Diagnosis stays human, and it requires understanding what the tool was supposed to do.

Maintaining a small internal tool runs to roughly a day a month. The average says very little, because those days arrive in clusters and rarely at a convenient moment. The week that costs you is the one where the tool breaks while three physicians call in sick, and the person who knows how to fix it is the one covering walk-ins. Nobody is on call for the tool. That is a good share of what you pay for in a subscription, and it is the line most often left out when the decision to build gets made.

Security patches, and the day it happens

A scheduling tool is an internet-facing app with a login page, and that page is the first thing attackers probe. Credential stuffing, no limit on login attempts, session tokens that never expire, a password reset that says too much: these are the classic defects of a first version, and an AI assistant does not flag them unprompted.

Patching raises a question that is easier to ask than to answer. When a vulnerability is published in a library your tool depends on, who finds out? An assistant will update the dependency the moment you ask, but it will not come and tell you an advisory went out last Tuesday. So either someone watches the advisories, or automated alerts were configured at the start, which a version built over a weekend almost never has.

What is at stake is not the medical record, since a schedule holds none. It is names, phone numbers, absences that hint at a health or family situation, and the location of every physician in the clinic at every hour of the week. A schedule is a map of who is where and when, and that map has value to somebody.

The day it happens, the logistics start before the technical work does. Law 25 requires logging the incident in a register and, if it presents a risk of serious injury, declaring it to the Commission d'accès à l'information and to every person affected. Declaring means knowing what was accessed, which means having logs in place before the incident. Without logs the scope of the breach cannot be established and you have to assume the worst, which is the most expensive and most embarrassing version of the same week.

Financially, the clinic carries the notification, remediation and downtime costs alone, with no vendor's insurance behind it. The Commission can impose administrative monetary penalties, and the law also provides for penal fines. The amount depends on the circumstances and the Commission publishes its own guidance, so we will not put a figure on it here.

The symmetry again. A vendor gets breached too, us included, and we hold no external audited certification. What differs is that there is a contract, a named responsible party, and a team whose job it is to notice and to fix, rather than one person who might find out reading their email on a Sunday evening.

The bus factor

The resident who wrote the tool finishes residency in July. The spouse of a physician who built it changes jobs. The contract developer is no longer available in February. In all three cases the code stays and the reason behind each rule goes.

It is that reasoning that goes missing, not the syntax. A file can be perfectly readable line by line and still be impossible to change, because nobody remembers why there is an exception on Tuesdays or what breaks if it comes out. Code produced with an assistant has its own version of the problem: it is often cleaner to read than hand-written code and less documented on the decisions, because the person who produced it did not write it, they accepted it. A year later they cannot always reconstruct their own reasoning.

Three tests measure this right now, without waiting for anyone to leave. Ask someone else in the clinic to add a new physician, change an on-call weighting rule, and restore last week's backup. If all three go through the same person, you know your bus factor, and it is one.

The master Excel file has exactly the same problem, which the Synchro vs Excel comparison goes into. An in-house tool does not fix it, it moves it onto a technology fewer people in the clinic can read.

Law 25 when you are the one shipping the software

A scheduling tool holds no patient data, which is as true of yours as it is of ours. It holds names, availabilities, absences and often phone numbers. An absence is not a neutral field: a three-month leave starting in February says something about that person's health or family. Those are personal information under the law.

The obligations on a Quebec private enterprise, an FMG included, do not change depending on whether the software was bought or built. You need someone responsible for the protection of personal information, a register of confidentiality incidents, notification to the Commission d'accès à l'information and to the people affected when an incident presents a risk of serious injury, and access and rectification rights honoured.

What changes when you are the one shipping it comes down to three points. A project to develop an information system involving personal information calls for a privacy impact assessment, and building your scheduling tool matches that description exactly. If the app is hosted outside Quebec, which is the case for most consumer hosting platforms, that communication outside Quebec calls for an assessment of its own. And the technical measures have nobody else to carry them: encryption, access management, session expiry, logging, tested backups and a written incident procedure.

The symmetry is worth stating plainly, because a vendor's comparison tends to leave it out. Buying does not make the obligation disappear. A clinic adopting Synchro still has to run its assessment, our providers operate mostly in American regions, and we hold no external audited certification. All of that is written on our Security and compliance page. What differs is that there is a vendor across the table to answer the technical half of the assessment, and a contract naming the measures. When you build, that vendor is you.

The math, over three years

Comparing a build cost to Synchro's price would be misleading, because the two numbers do not contain the same things. Our price includes hosting, updates, security patches and support. A build cost includes the build. So here are the two columns brought to the same contents, for a 30-user FMG.

30 users	Setup	Hosting, 3 years	Maintenance and patches, 3 years	Total over 3 years
Synchro	Included	Included	Included	$10,800 CAD
In-house, simple version	$1,800 to $3,000	about $1,800	about $4,000	$7,600 to $8,800
In-house, production tool	$9,000 to $12,000	about $1,800	about $8,100	$18,900 to $21,900
In-house, handed to a developer	$30,000 to $40,000	about $1,800	about $27,000	$58,800 to $68,800

The assumptions, to be swapped for yours: $10 CAD per user per month billed annually across 36 months without deducting the free month, roughly fifty dollars a month of hosting, half a day of maintenance a month for the simple version and a full day for the complete one, at a loaded rate of $30 an hour. The developer row assumes maintenance is bought back at the same hourly rate. Plenty of clinics take it back in-house instead, which moves the cost rather than removing it.

The simple version comes out cheaper than we do, and that is true. It also does not do the same thing: it produces a draft the coordinator reviews by hand, with no fairness weighting, no replacements and no notifications. Against Synchro that is a difference in product before it is a difference in price. The production tool costs roughly double our subscription at 30 users, and the version handed to a developer is never in the running.

Those totals answer a narrow question, the one about money. Three things that weigh just as much are not in them, and none of the three goes into dollars.

Efficiency first. A tool that produces a valid schedule and a tool that produces a good one leave very different amounts of work behind them. Every badly assigned slot comes back as a phone call, a swap to approve or a manual correction, and that is the time the coordinator counts at the end of the month. In our pilot FMG, building the schedule went from about 30 hours a month to one. An in-house tool can get there, but the gap between the two outcomes appears nowhere in a build cost.

Durability next. The table prices three years, which assumes the tool lasts three years. In the meantime the team grows, a satellite site opens, an on-call rule changes, the person who built it leaves. A product keeps moving through all of that. An in-house tool moves when someone has the time to move it.

Consistency last. A schedule produced by the same rules, the same way, every period, holds up when someone disputes it. A schedule touched up by hand by the one person who knows the exceptions drifts slowly, and the drift does not show until a physician compares their on-call count with a colleague's.

Team size then moves the dollar figure, because our price follows it and a build cost does not. The two curves cross around 60 users. Below that, the subscription costs less than building and maintaining the equivalent. Above it, the in-house tool takes the lead on paper, provided the maintenance hours genuinely exist somewhere in the organization.

What is left fits in no cell at all: the month the tool breaks and the team falls back to Excel, and the wear of carrying a piece of software the whole clinic depends on without being paid for it.

Questions to answer before writing the first line

Eight questions, answered in writing before you start rather than after. Almost none of them is about technology.

What to check	The question to answer
Who carries the tool	Who, by name, fixes a breakage at 4 p.m. on a Friday two years from now? Write the name down. If there is only one, that is your bus factor.
The real milestone	On what date does the coordinator stop maintaining the Excel file alongside? As long as both run, the tool is not delivered.
The unsolvable case	When no assignment satisfies every constraint, what does the tool do? If it produces a schedule anyway without flagging it, it is dangerous.
After publication	Trigger a withdrawal at 4 p.m. on a Friday and follow the replacement all the way through, notifications included. It is the bulk of the work and it never shows in a demo.
Access	Who can see whose absence? Answer before writing code, not after the first sick leave visible to the whole clinic.
Security	Who finds out that a vulnerability was published in a library the tool depends on, and who applies the patch? If the answer is "nobody yet", that is the real answer.
Law 25	Who runs the privacy impact assessment, where is the data hosted, and who answers the Commission d'accès à l'information after an incident?
The exit	If the project is abandoned eight months from now, what is left? Can anyone other than the author export the data?

The second one is the most useful of the eight. A date written down in advance turns an open-ended project into one that either succeeds or fails, and both answers beat eighteen months of double maintenance.

Building is the right call if…

• Your scheduling problem looks like no product on the market: a research unit, an interdisciplinary structure that is not an FMG, a hospital-clinic-teaching mix with rules nobody else has.
• Someone in the organization has maintenance written into their job, with a named successor. An enthusiastic volunteer does not count.
• The tool does one well-bounded thing: display the on-call list, collect availabilities, produce a report. That is the 60-to-100-hour tier, and it works far better than building a full assignment engine.
• A contract requires specific hosting, Canadian for instance, that your vendor does not offer. We do not offer it by default either.
• You are a large team, past roughly sixty users, where the subscription eventually exceeds the cost of building and maintaining the equivalent.
• You are building a prototype to understand your own constraints before buying anything. That is the best use of two afternoons with an assistant.

Synchro is the right call if…

• You want to publish a schedule next month rather than next fall.
• The hours you would spend building belong to a coordinator already at about thirty hours a month on the schedule, or a physician whose half-day is expensive.
• Nobody in the clinic wants to be on call for a piece of software on top of being on call for patients.
• The hard part at your clinic is what comes after publication: withdrawals, replacements, on-call transfers and notifications.
• Your physicians have many constraints in many shapes and you want them writing their own in plain language rather than fitting into a form someone has to code.
• You want someone else carrying updates, tested backups and the incident procedure.
• You prefer a predictable monthly cost you can cancel over a project whose opening estimate is the only thing known for certain.

Further reading

• FMG scheduling software
• Walk-in distribution
• On-call scheduling software
• Synchro vs Excel comparison
• 8 moments that wreck your FMG schedule
• Security and compliance
• Pricing
• All Synchro comparisons