What every appointment actually makes or loses
Starting with the 33% of overhead your current model counts twice, which is why every hygiene appointment in your spreadsheet comes back red. Inside: the corrected arithmetic, the architecture, the data model, six schematics, the integration plan, and what it costs to build.
Prepared forDr. Hector Cabreraand Derek at Grassroots Technologies
We went through the workbook sheet by sheet and recomputed every appointment in it. Three things are worth stating before any architecture, because two of them change what gets built.
Costing supplies down to the individual gauze square, per procedure, is the work almost nobody is willing to do. You and your assistants already did it, across 23 CDT codes with supply and lab cost separated.
What it means for the build: that data seeds the procedure library directly. It does not need redoing, and it is a genuine competitive asset. A competitor’s generic percentage assumption will not match a dentist who costed a crown to two cents.
The model divides all practice overhead by doctor hours, then charges that rate against every appointment including hygiene. Hygiene runs in a second chair at the same time the doctor produces, so the same rent and front desk payroll gets charged twice on any day both chairs run.
The effect: the sample day is charged $4,045 of overhead against a real daily overhead of $3,034. That is why every hygiene appointment in the sheet reads red. Section 02 shows the correction and what it changes.
Expected revenue is typed in by hand on every row. There is no table anywhere in the workbook mapping an insurance plan and a CDT code to an allowed amount. That table is the entire product.
Where it comes from: you said it already lives in the practice management software, because that is where treatment plans pull from. You are right, and on some systems it is directly readable through the API. That removes what looked like the hardest problem in the project.
Allocate on chair hours, not doctor hours
Figure 1 · Overhead allocation, sample day of 11 appointments
Fixed overhead buys capacity: chairs, staffed and available. The right denominator is therefore the chair hours the practice makes available, and each appointment absorbs overhead in proportion to the chair time it occupies, whoever is sitting in it.
The check: revenue of $6,654.00 less direct costs of $2,107.26 less true daily overhead of $3,033.95 gives $1,512.79 for the day. Your sheet reports $501.48. The $1,011.32 difference is exactly the double count, arrived at from a completely different direction.
What it changes: two of six hygiene appointments flip from red to green. The other four stay red, and that is the finding that matters most.
| Appointment | Sheet | Corrected |
|---|---|---|
| SRP 4+, Delta, 70 min | -$183 | +$39 |
| Prophy + fluoride, FFS, 50 min | -$109 | +$49 |
| Prophy + exam, FFS, 50 min | -$204 | -$46 |
| Perio exam, Delta, 50 min | -$197 | -$39 |
| Comp exam + FMX, 90 min | -$400 | -$116 |
| Implant D6010, Delta, 120 min | -$762 | -$383 |
A hygiene chair costs $243.62 an hour to run once overhead and the hygienist’s time are counted. Industry hygiene production runs $145 to $175 an hour. Hygiene is structurally underwater on a fully loaded basis in most practices, and that is what hygiene economics are, not an error in the model.
So the software reports two numbers on every appointment. What it contributes, meaning revenue minus the costs that genuinely disappear if the appointment does not happen, which is the number for deciding whether to keep a plan or do a procedure. And what it costs fully loaded, which is the number for deciding whether the practice, configured this way, works. Any tool showing only the second one tells you to shut down hygiene. You already know that would be wrong, because hygiene is where diagnosis, treatment acceptance and retention come from.
The verdict unit follows from this. Red, yellow and green are computed on margin per scheduled chair hour, with separate thresholds for a doctor chair and a hygiene chair, calibrated against the practice’s own required rate rather than a fixed dollar figure. Same day: an SRP at +$39 over 70 minutes is $33 an hour. A crown at +$857 over 70 minutes is $735 an hour. Both are green in dollars. Only one is worth the chair.
Which plans and which procedures are worth your chair
On the call you asked three questions, and all three are really the same question. Is this insurance worth taking. Is this procedure worth doing. Should I still be doing root canals for a hundred dollars. None of them is answered by a list of yesterday’s appointments. They are answered by one grid.
Figure 2 · Margin per chair hour, procedure against plan. Every populated cell is computed from your own sample day. The blanks are the point.
Six cells out of thirty. That is everything your current model can tell you, and it is why “should I drop Delta” is currently a feeling rather than a number. Load the fee schedules and the grid fills in. Same crown, same seventy minutes, same cost of goods, five different answers.
It needs no appointment data to work. Revenue comes from the fee schedule, cost comes from the procedure library and your overhead rate. The grid can be produced the day your fee schedules are uploaded, before anything is connected to your practice management software.
Which also lets you price a plan you have not signed. You said fee schedules are regional and usually obtainable. Feed in a carrier you are considering and you can see what joining them would actually yield, before you commit. Nobody sells that today.
You told us you stopped doing root canals because it takes forever and pays a hundred dollars. That was the right call, made the hard way, one procedure at a time, over years.
This is that same decision as a single cell in a grid, available for every procedure and every plan you are contracted with, before you do the work rather than after.
| The grid (primary) | The appointment (drill down) | |
|---|---|---|
| Answers | Is this plan and this procedure worth doing at all | What did this specific appointment actually yield |
| Built from | Fee schedules and standard times | Real appointments, real durations |
| Needs an integration | No | Yes, or an upload |
| Available | Day one | Once data flows |
| Drives | Drop the plan, stop the procedure, reprice | Coach the provider, fix the schedule |
The gap between the two is where the real insight sits. The grid says a crown at seventy minutes yields $735 an hour. The appointment data says your newer associate is taking two and a half hours, so it actually yielded far less. Neither number is wrong. The difference is a coaching conversation, and it only exists because both views run off the same engine.
One honest caveat. The grid tells you the answer per procedure. It does not tell you how much that answer matters until we know your volumes. A plan losing twenty dollars across four hundred procedures a year is a far bigger problem than one losing two hundred across three. The grid is directional from day one and becomes decisive once a few months of real appointments have flowed through it.
You defined the minimum version yourself, and we are holding that line: “what is the minimum that just tells me was this appointment profitable, and then it gets pushed to your email or something.” Phase 1 delivers the grid plus that email. Read only, nothing written back into your systems, no scheduler overlay.
Why the overlay waits. It is what you actually want and it is what makes the product stick. It is also where nearly all the risk and cost live, and it depends on a vendor decision nobody has made yet. If the numbers are wrong, an overlay makes them wrong faster and in front of more people.
Where this sits against what already exists. Dental Intelligence and Practice by Numbers read the same practice management systems and report the same kinds of metrics, production per hour and adjustment percentages among hundreds of others. Competing with them on reporting loses. What none of them does is put a true loaded cost against a specific plan and a specific procedure. They tell you how the practice did last month. This tells you which contracts and which procedures are worth keeping.
Figure 3 · System architecture
Postgres, multi tenant, with tenant isolation enforced by the database rather than by remembering to filter. Twelve core tables. The one in blue is the spine.
Figure 4 · Core data model. Blue is the fee schedule spine.
Resolution order when pricing a procedure. Plan, code, exact region and date in force. Then plan, code and date without region. Then the practice’s own fee for service rate. If none of those match, the appointment is flagged and the revenue is shown as unknown. It is never guessed. A financial tool that quietly invents a number is worse than one that admits a gap.
Everything material is effective dated. Fee schedules, compensation, procedure costs, capacity and overhead. You noted Delta has not updated its schedule in about five years, so schedules are stable but stale. When one does change, last quarter’s reported profit must not silently move.
Every score keeps its own receipt. Each computed figure stores the assumptions in force when it was computed. If you question a number six weeks later, we can rebuild it line by line rather than argue about it.
Supply costing has two modes. New practices default to a percentage of revenue, seeded at the 4% figure from your own profit and loss, so setup takes minutes. Individual high value codes can be upgraded to your per code precision where it changes a decision. A $2 prophy does not need two decimal costing. An $838 implant does.
CareStack’s public developer documentation covers patients, medical conditions, payment summaries, communications, documents and treatment codes. It does not publicly document appointments, fee schedules, insurance plans, providers or operatories, which is five of the six things this product needs to read. Their marketing material says the programme provides “access to all key operational data points,” which is not the same as documentation.
It may well support all of it and simply not publish the detail. We are not going to assume either way, and we will not invent endpoint names to make a diagram look complete. Before the roughly $5,000 developer registration is committed, we get the endpoint inventory in writing. Your account and Derek’s relationship get that answered in days, at no cost. Section 08 shows where this sits in the plan.
Figure 5 · Capability negotiation per data domain
| System | Access | Cost | Fee schedules readable |
|---|---|---|---|
| Open Dental | Public REST, self serve key | $0 to $35 | Yes, documented |
| CareStack | REST, webhooks, extracts | ~$60 + fees | Not documented |
| Denticon / Planet DDS | Partner registration | Not published | Unknown |
| Dentrix Ascend | REST, approved vendors | $47 | Unknown |
| Dentrix on premise | Local database, on site agent | $10k + royalty | Agent required |
| Eaglesoft | Local, authorised partners | Not published | Unknown |
| Curve Dental | No public API | n/a | Upload path only |
Costs are per location per month unless noted. Open Dental matters disproportionately because it publicly documents every endpoint this product needs, including fee schedules, on a free read tier, across more than 12,000 practice installs. It is the cheapest route to a second customer and the reference implementation that proves the adapter pattern generalises.
Figure 6 · Nightly sync, with the failure path
Does the system need to hold patient names and dates of birth? Our recommendation is no. The report is fully actionable without them: “9:00am, 90 minutes, D2740, Delta, +$212 an hour” tells you everything, because the decision you are making is about a plan and a procedure, not about a person. Patient records stay in your practice management software, and we hold a one way reference that cannot be turned back into a name outside your own system.
That choice materially reduces the compliance surface and the running cost. If you want names on the report, that is a legitimate call, it just needs to be a deliberate one, because it changes the hosting, the agreements required and the monthly floor.
| Layer | Recommended | Why this one |
|---|---|---|
| Application | Next.js on Vercel | Our standard. The first release has very little interface, so the weight belongs in the engine, not the front end. |
| Database | Postgres, row level isolation | Effective dated fee schedules and per tenant separation enforced by the database rather than by application discipline. |
| Authentication | Clerk organisations | Practice, location and role map directly onto it. Building multi tenant permissions by hand is where projects like this lose weeks. |
| Scheduled work | Durable job queue | Sync is long running, rate limited and retry heavy. Ordinary serverless timeouts will not hold it. The one place not to improvise. |
| Resend | The deliverable is an email, so it gets a real template rather than a text dump. | |
| Credentials | Encrypted, referenced, never stored in the database | Practice management keys for many practices are the highest value target in the system. |
| Monitoring | Error tracking plus a per practice sync health view | The operational risk here is not a slow page. It is a sync that fails quietly. |
| Money maths | Decimal, never floating point | Non negotiable in anything that reports currency. |
If the answer on patient data is yes, the stack moves to AWS with managed database, queue and email under a single business associate agreement. It is a well understood substitution and it is priced differently. We would rather present the fork than quietly pick for you.
Six phases. Each one approved on its own, and you are never committed past the one you are in.
Vendor verification. Written endpoint inventory from CareStack. Confirmed capability map and pricing. No registration fee paid before this completes.
25 hrs · 1 week
UI foundation. Design tokens, the verdict colour system, the grid, the upload and settings screens, the email template. Runs alongside the backend, so it does not extend the timeline.
132 hrs · runs parallel
The grid, and prove the number. Plan and procedure profitability grid, costing engine, upload path, procedure library, overhead pools, the morning email, idle chair reporting. Your eleven sample appointments as the test suite.
314 hrs · 7 to 9 weeks
Live connection. Adapter, credential vault, scheduler, rate limiting, retry, sync health. No more uploads.
169 hrs · 4 to 5 weeks
Volume weighting and the dashboard. Phase 1a tells you which plans and procedures are underwater per unit. This tells you how much it matters, weighted by how often you actually do each one. Scheduled against actual time. Second system integrated to prove the pattern.
240 hrs · 6 to 8 weeks
The overlay. Feasibility test first, then build. Priced after the test, not before.
Spike, then scoped
Promised against paid. Reconcile remittance data to the fee schedule per plan and per code. The strongest differentiator available.
Scoped after Phase 1
Why Phase 1a stands alone. It has no vendor dependency at all. It proves the model is believable before a dollar of integration is spent, and it works for a prospect on any practice management system, including ones with no API.
Why Phase 3 is not priced. No practice management vendor offers an official way to put third party information onto their scheduler screen. It is achievable, but the route decides the cost, so we test before quoting. We would be suspicious of anyone who fixed a price on it today.
What we would need from you. The fee schedule export, a recent profit and loss for overhead, confirmation of how many chairs run on which days, and how any associate is compensated. Roughly an hour of front office time.
Two structures. Both are real offers, and the second is the one we think fits where this actually is.
You own it outright. We build, deliver and hand over. Phases are sequential and separately approved, and you are never committed past the one you are in.
Development is billed at $250 per hour, design at $175. The hours below are our real estimates, not padded ranges, and they already account for how we actually build now. A meaningful share of this work is AI assisted, which is why the totals are lower than a traditional agency estimate for the same scope. Where AI does not help, and on this project that is the costing engine and the practice management integration, we have held the hours rather than pretend they compress.
| Phase | What you get | Hours | Cost |
|---|---|---|---|
| 0 | Vendor verification, confirmed capability map | 25 | $6,250 |
| 0b | UI foundation: design tokens, the verdict colour system, the grid, upload and settings screens, email template | 132 | $23,100 |
| 1a | The plan and procedure grid, costing engine, upload path, the morning email | 314 | $78,500 |
| 1b | Live practice management connection | 169 | $42,250 |
| 2 | Dashboard and second system integrated | 240 | $60,000 |
| 3 | Overlay feasibility test | 50 | $12,500 |
| 4 | Promised against paid reconciliation | 85 | $21,250 |
Phase 3 is deliberately quoted only as the feasibility test. We will not fix a price on the overlay build until the test tells us which of the three approaches actually works, and we would be suspicious of anyone who did.
Naming and identity are held separately. A product name, wordmark and mark is roughly 30 hours, about $5,250, and we would rather do it once. Who the brand belongs to depends on how this is structured commercially, and that is a conversation still to have. The interface work above does not wait on it.
Vendor fees are paid by you directly, not billed through us. The CareStack developer registration, currently understood to be around $5,000 and confirmed in writing at Phase 0, buys your practice access to your own data. It is yours, it stays yours, and there is no reason for it to sit on our invoice.
You said you love partnerships, and that when everybody is invested the rising tide lifts all boats. We agree, and this is a market we want to be in.
The alternative is that 561 Media builds the early phases at a substantially reduced fee and takes a stake in what gets built, rather than invoicing the figures above. You contribute the domain expertise, the pilot practice, the supply costing you have already built, and the introductions into the dental market. We contribute the build and carry the risk with you.
We would re cut the arrangement after Phase 1a, when we are both looking at evidence about whether dentists other than you want this, rather than at a pitch. The shape of that stake, and what a reduced fee looks like against the numbers above, is a conversation to have properly rather than a number we would put in a document before agreeing the principle.
Option B fits where this is. You have the insight and the market access, we have the build capability, and neither of us yet knows whether dentists outside your own practice will pay for it. Phase 1a is designed to answer that cheaply. Structuring the early phases as a partnership means we both find out without either of us carrying the whole risk.
| Item | Cost | Note |
|---|---|---|
| CareStack API access | ~$60 / location / mo | Plus an account minimum and the one time registration. All figures confirmed in writing at Phase 0. |
| Open Dental API access | $0 to $35 | Free at the level the first release needs. The paid tier is only required for the overlay. |
| Hosting, email, monitoring | Low hundreds / mo | Shared across every practice on the platform. |
| Accounting integration | Variable | Kept optional in the first release, because the metering cost cannot be sized until real call volume exists. |
What this means if you sell it. The practice management vendor takes its cut on every seat forever, so selling below roughly $199 per location per month does not work. $299 to $499 is where this should land, plus a one time onboarding fee of $500 to $1,000 covering the fee schedule import, which is the only genuinely manual part of setup. Worth knowing now, while pricing is still a decision rather than a constraint.
Everything quoted above is engineering. Three real costs sit outside it, and we would rather name them now than have them appear as surprises later.
| Not in the build figure | What it actually is |
|---|---|
| Platform running costs | The monthly cost of keeping it live. Currently around $300 a month in total, shared across every practice on the system, and it stays there because of how the stack was chosen. |
| Getting in front of other dentists | Dentists do not buy practice software off a search ad. This sells through trade shows, study clubs and CE circuits, the dental podcasts and forums, and practitioners other dentists already trust. Booth space and speaking slots are lumpy, five figures at a time, and they are the channel. |
| Support and onboarding at volume | Fine at five practices. A real function at forty, when people are calling about numbers they want explained. Budget for it before it is on fire, not after. |
Operational cost is a design decision, not an accident. The reason this runs at roughly $300 a month rather than several thousand is that we picked the free read tier on Open Dental, shared one set of infrastructure across every practice, and refused to over provision for scale that does not exist yet. Those are choices made by people who expect to still be running it in two years. A firm that builds and hands off has no particular reason to care what it costs you to operate afterwards, and it usually shows.
On getting in front of other dentists, we will be straight with you. This is not a market you win with search ads and a content calendar, and we are not going to pretend otherwise. Dentists buy practice software because someone they respect at a study club, a conference or on a podcast told them it changed how they run their operatory. The most valuable distribution asset in this project is you. You are a practising dentist with a genuinely original argument and the numbers to back it, and that is worth more than any campaign we could run.
What we are good for around that is everything that has to exist for those conversations to convert. The positioning and the language, the booth and the deck, the demo that survives a sceptical practice owner poking at it, the case study built from your own numbers, the follow up that does not drop leads, and the site people land on afterwards. We would also keep the operating cost honest while it scales, which is the part nobody notices until it is a problem.
Every project like this has these. Listing them is not hedging, it is how we decide what order to build in.
| Risk | Likelihood | How the plan handles it |
|---|---|---|
| CareStack cannot serve the data | High | Verified in writing at Phase 0 before any fee is paid. The upload path ships regardless, so the pilot is never blocked, only made less automatic. |
| The tool reads as fire your hygienists | High | Contribution margin is the headline number, thresholds are set per chair type, and the idle chair cost is reported separately so hygiene is judged on hygiene economics. |
| You do not believe the number | Medium to high | Both numbers shown side by side, every score keeps the assumptions it was computed from, your own eleven appointments are the test suite, and an unresolved fee is flagged rather than guessed. |
| Fee schedule is stale or the wrong file | High | Schedules are dated, their age and source appear on every report, and from Phase 4 they are checked against what payers actually paid. |
| Associate compensation modelled wrong | High | Both hourly and percentage of production supported from the first release, dated, and confirmed during setup. |
| A sync fails quietly | Medium | The day is marked stale, the email says what it was computed from, and failures alert rather than disappear. |
| Accounting integration cost | Medium | Kept out of the required path. Overhead can be entered directly, so the integration is a convenience rather than a dependency. |
| The overlay proves impossible | Medium | Tested before it is priced, with a companion display fallback. Nothing in the first release depends on it. |
| A competitor adds per procedure cost | Medium | The defensible parts are your own supply costing and the reconciliation of promised against paid. Speed to a working pilot matters more than feature count. |
Writing anything back into your practice management software or your accounting. Patient lifetime value and loss leader analysis. Claims submission or eligibility checking. Any clinical recommendation about whether a procedure is appropriate. A mobile app, since the email is the mobile experience. Systems requiring software installed inside the practice network. And the light above the operatory door, which was a genuinely good idea and comes back as the fallback for Phase 3.
1. We send the CareStack questions. Costs nothing, takes days, and it decides whether the live connection is straightforward or needs a different route. This should go out whatever else you decide.
2. You answer six things about the practice. How many chairs produce and on which days. Whether Dr. Parchment is an associate and how they are paid. What you collect against allowed amounts. Whether the Cigna crown at $1,775 and the Delta implant at $1,100 in the sample are real or data entry errors. And what you are targeting for your own compensation, because that sets the line between yellow and green and without it we would be picking a number arbitrarily.
3. You pick a structure. Straight build or partnership, and we start Phase 0 the week you say go.
We turn down most software projects that come to us, because most of them do not make sense. Dental is a market where technology adoption is slow enough that a well built tool still has room, the practices have money, and the specific thing you are describing does not exist. The analytics tools in your market report what already happened. None of them tells you whether the next ninety minutes is worth selling.
Questions before you decide? Book a time or reply to the email this came from.