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.
We would rather own a slice of something that works
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. So rather than quote you a build and hand it over, this is written as the thing we would actually do together. Here is what that looks like in specifics rather than in principle.
| You | 561 Media |
|---|---|
| The clinical judgement and the original insight. This was your idea and it is a good one. | The full build, engineering and design, across every phase. |
| The supply and lab costing you already built, code by code. Nobody else has done that work. | A materially reduced fee, with the balance carried as our investment. |
| The pilot practice and the real data to prove the model against. | Hosting, infrastructure and keeping the running cost honest as it scales. |
| Standing with other dentists. In a market that sells on peer recommendation, that is the distribution. | Positioning, the collateral, the demo, and the commercial operating side. |
A new company, jointly owned, formed before any work starts. It owns the product, the code, the brand and the customer relationships. Neither of us builds anything valuable inside our own business and then argues about it later.
Proposed split: 50/50. Equal partners, because that is what this actually is. You bring the insight, the clinical authority and the standing with other dentists that makes it sellable. We bring the build, the money to do it, and the operating side. Neither half works without the other, and we would rather start from that than from one of us being the senior party.
Both sides assign in what they bring. Your clinical model and costing library, our code and design. Both become company property on day one, so there is never a question about who owns what if this gets bought.
Day to day stays where the competence is. You lead clinical direction and the market. We lead the build and operations. The decisions that change the company, taking money, selling it, changing the split, need both of us.
A revenue share pays out sooner and is simpler to write, so it is usually the first instinct. It has one flaw that matters here.
You told us the ambition is to build this into something one of the larger dental companies wants to buy. In an acquisition a revenue share typically pays nothing. The buyer terminates or renegotiates it, and whoever funded the build is left with the monthly cheques they already banked.
Equity is the only structure that follows the outcome you are actually aiming at, and it puts us both on the same side of every decision along the way.
$60,000 to a working product running on your live data. That is everything below, four phases, 680 hours of engineering and design.
| Phase | What it delivers | Hours |
|---|---|---|
| 0 · Vendor verification | Written capability inventory from CareStack in hand, and the integration path decided | 25 |
| 0b · UI foundation | Design system, the grid layout and the email template, approved by you before anything is built | 132 |
| 1a · The grid, live | Your fee schedules loaded, the grid filled in, the costing engine running, your accounting connected, first morning email delivered | 354 |
| 1b · Live connection | Nightly sync running against your practice management software, uploads retired | 169 |
| A working product on live data | 680 | |
| When | Covers | Amount |
|---|---|---|
| On signing | Vendor verification, the design foundation, and the start of the build. | $18,000 |
| When Phase 1a is accepted | The grid live on your own data, and a correct morning email five days running. | $18,000 |
| When Phase 1b is accepted | The nightly sync running against your practice management software, uploads retired. | $24,000 |
| Total | $60,000 | |
You pay as the work lands. Nothing is due for a phase you have not seen. Each payment is tied to something you can check yourself rather than to a date on a calendar, and the two larger ones come after the product is doing the thing it is supposed to do.
What we are carrying. This work bills at $160,100. We are doing it for $60,000 and taking a stake instead of a fee, so roughly $100,100 of engineering and design goes into the company as our investment rather than onto an invoice. The first payment is sized to cover our actual cost of getting started, which is what keeps this a partnership rather than us quietly acting as your lender.
The fee and the split move together. If you would rather pay more of the build in cash, our share comes down. If you would rather pay less, it goes up. Both numbers are a conversation and neither is fixed until we agree the shape.
The dashboard, the volume weighting, the scheduler overlay and the remittance reconciliation are funded by the company once there is revenue, on a normal services agreement at standard rates. We are not asking you to fund a company that then gets free engineering forever, and you are not asking us to provide it. Support and maintenance work the same way.
Four things came out of that conversation that were not in this document before. They are here because they came from you and Derrick, and because they changed the product rather than just the pitch.
| What was raised | Where it lands |
|---|---|
| Nothing depends on the office network. Derrick's point, and the right one. If a practice loses its circuit, or the box in the closet dies, it should not lose the software. | The product is cloud hosted with no on-premise component and no local install. There is nothing in a practice to fail, back up or replace every five years. This was already the architecture and it is now written down, because every practice in the beta will ask. |
| The market fee data comes from the practices, not the insurers. Your point on the call: we do not have to ask a carrier what they pay in a zip code. | As practices come on, the platform builds a picture of what each plan actually allows, by procedure, by area. That is a real asset, it gets more valuable with every practice added, and it removes the dependency on carrier cooperation that would otherwise be the single biggest thing outside our control. |
| Let them see two codes for free. Also yours, and it is the best distribution idea in the whole plan. | A prophy and a filling, unlocked. The crown and the implant, which is where the money actually is, behind the subscription. A dentist who sees two real numbers from their own practice will want the other thirty. Scoped after the working product, not before it. |
| Nobody has to dig up a year of P&Ls. Your concern on the call, and the fair one. Assembling a year of statements is the thing that stops a practice ever getting started. | Practices connect QuickBooks or Xero and the numbers come across on their own. It is cloud based, so there is nothing to install and nothing running in the office. Honest caveat: every practice codes its books differently, so we still walk through which accounts map to which costs once. The connection removes the homework, not the conversation. Added to the build at our cost. |
| Naming, brand and marketing are not a line item. Raised when we noticed the build had no design or identity in it. | Naming, the identity, the site, the deck, the booth, the content and the advertising setup are contributed by us as partners rather than billed to the company. They do not appear in the $60,000 because they are not being charged for. |
When the grid is live and a handful of dentists who are not you have looked at it, we both know something we do not know today: whether this is a business or a very good internal tool. Either side can adjust the terms or stop at that point. We would rather build that gate in now than discover in a year that one of us has been carrying the other.
| Term | Why it matters |
|---|---|
| Change of control | The arrangement has to survive a sale rather than evaporate at the moment it is worth the most. This is the whole reason for equity over a revenue share. |
| Vesting against contribution | On both sides. Your value is being the clinical voice and the credibility with other dentists. Ours is building and running it. If either of us stops, the stake should reflect that. |
| A buyout path | If this works and you want it all back, there should be an agreed way to do that rather than an argument. |
| What each side owns going in | Your costing library and clinical model, our code and design. Assigned to the company on day one, cleanly. |
Vendor fees are paid by the company directly. The CareStack developer registration, currently understood to be around $5,000 and confirmed in writing at Phase 0, buys access to practice data. It is a cost of the business, not a line on our invoice.
Naming and identity are held until the company is formed. A product name, wordmark and mark is roughly 30 hours, and we would rather do it once, after we know whose brand it is. The interface work does not wait on it.
| 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 when the company sells 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.
Everything above is engineering and design. Three real costs sit outside it, and the company will carry them.
| 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, which under this structure we are.
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 here is you.
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.
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. We agree the split and form the company. The proposed shape is in section 09. Once that is signed and the entity exists, Phase 0 starts 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.