Most software cost articles are written by people who have never had to keep the thing running afterwards. They price the build, publish the range, and move on. Nobody comes back a year later to say which estimate was wrong.
Denti360 is our own product. We designed it, built it, launched it, priced it, and we still operate it for real multi-branch dental clinics. That means there is no invoice to publish, because we never sent ourselves one. What we do have is something more useful: a full accounting of where the work went, and the benefit of having lived with every shortcut we took.
So this is a reconstruction, not a receipt. Every figure below is priced at the blended rate we publish everywhere else on this site, about $20/hour for a senior offshore team, applied to work we actually did. Where a number would be a guess, we say so rather than inventing precision.
If you want the general version of this arithmetic rather than one product's, the SaaS development cost guide prices the pieces feature by feature, and the healthcare app development cost guide covers what compliance scope does to the total.
What Denti360 does, which is what sets the price
Scope drives cost far more than technology choice does, so it is worth being specific about what this product is before pricing it.
Multi-branch dental practices run on a patchwork: one system for appointments, spreadsheets for patient histories, something else for invoicing, and no single view across locations. The owner of a four-branch practice genuinely cannot answer "how did we do last month" without three exports and an afternoon.
Denti360 replaces that patchwork with one system:
- Appointments across branches and chairs, with reminders and a day view the front desk can actually work from.
- Patient records: histories, treatment plans and documents in one file, available at any branch.
- Billing: invoicing, payments and receivables tied to each visit and each treatment.
- Multi-branch operations: one account, many locations, shared data with per-branch views and control.
- Expense tracking: every clinic outflow logged by category and amount, across branches.
- Dashboards: patients, appointments and income against expense at a glance, broken down by doctor and by service.
Read that list as a buyer and it looks like six features. Read it as an engineer and it is one platform decision (multi-branch) plus five features that all inherit from it. That distinction is the whole cost story, and we come back to it below.
In the tiers we publish, this is not an MVP. It sits in Growth SaaS territory: multi-tenancy, roles and permissions, real billing, admin tooling and reporting. Our guide puts that band at $10,000 to $100,000 over four to seven months, which is honest but wide. The point of this post is to narrow it with a real example.
The build, priced line by line
Here is the work, reconstructed. Ranges rather than points, because the same line item lands differently depending on how disciplined the scope stays.
| Line item | What it covers | Typical cost |
|---|---|---|
| Discovery and workflow mapping | Sitting with front-desk staff and clinicians, mapping the day as it actually runs, before any screens exist | $1,200 to $2,500 |
| Multi-branch data model | Tenancy and branch scoping designed into the schema from the first migration | $1,500 to $3,000 |
| Roles and permissions | Owner, branch manager, clinician and front desk, each seeing a different slice of the same data | $1,500 to $4,000 |
| Appointments | Scheduling across branches and chairs, conflict handling, reminders, day and week views | $3,000 to $6,000 |
| Patient records | Histories, treatment plans, document upload and retrieval, cross-branch access | $2,500 to $5,000 |
| Billing and receivables | Invoicing tied to visits and treatments, payments, part-payments, outstanding balances | $3,000 to $6,500 |
| Expense tracking | Categorised outflows per branch, feeding the profitability view | $1,000 to $2,000 |
| Dashboards and reporting | Income against expense, breakdowns by doctor and by service, per branch and consolidated | $2,000 to $4,500 |
| Design system and front-desk UX | Component library, then the disproportionate care the booking screen needs | $1,500 to $3,500 |
| Infrastructure, deployment, backups | Cloud hosting, environments, CI, automated backups and restore testing | $1,000 to $2,500 |
That totals roughly $18,000 to $39,500, which places a Denti360-shaped product in the lower half of the Growth SaaS band. A US or Western European agency quoting the same scope at $120 to $250 per hour would be somewhere between $110,000 and $250,000, and the spread is cost of living rather than skill. The rates table in the SaaS cost guide shows that arithmetic in full.
Two things that table does not capture, and which matter more than any single row in it.
Four things that cost more than the feature list suggests
1. Multi-branch is a data model decision, not a feature
"Support multiple branches" is five words in a spec and a fork in the road in a schema. Every table, every query, every permission check and every report has to know which branch it belongs to, and which branches the person asking is allowed to see. Get it right at the start and it costs a few thousand dollars once. Get it wrong and you are not adding branches later, you are rewriting the application while paying customers use it.
It is the claim in our SaaS guide we are most confident about, because it is the one with the least ambiguity: tenancy is painful to retrofit, and everything else is negotiable. Denti360 was designed with branch scoping in the schema rather than layered on top, which is why a clinic opening a fourth location is a configuration change rather than a project.
If you are pricing a similar build and a vendor treats multi-location as a line item to be added in phase two, that is the single most expensive sentence in their proposal.
2. Billing is where clinics decide whether to trust you
Invoicing looks like a solved problem until you meet real dental billing. A treatment plan spans months. A patient pays part of it today and part after the next visit. Insurance covers some procedures and not others. Someone gets a discount because they are a returning patient and the owner said so. A receipt has to be reprintable a year later, unchanged.
None of that is technically hard. All of it is detail, and detail is where estimates go to die. The trap is that billing looks finished long before it is, because correctness in billing is not "the arithmetic is right", it is "the arithmetic matches what the clinic told the patient". Those two things diverge in exactly the cases nobody specced.
Budget for billing to take longer than its row in any feature table implies. It is the one screen where a bug does not annoy the user, it embarrasses them in front of their customer.
3. Permissions are a tax on every feature built afterwards
A permissions model is not a feature you finish. It is a cost applied to everything you build from that point on. Once four roles exist, every new screen needs four answers about who can see it, four about who can change it, and a test for each.
The line item above says $1,500 to $4,000, and that is honest for building the model. It undercounts the compounding: perhaps ten to fifteen percent added to every feature that comes after. Our MVP cost guide puts the same point more bluntly, a fourth user role always costs more than a third API.
4. The front desk is the real user, and the real user is busy
The owner buys the software. The front-desk coordinator uses it two hundred times a day with a patient standing in front of them and a phone ringing.
That gap is expensive to close, and it is not closed by design polish. It is closed by watching someone work. A booking screen that demos beautifully and takes four clicks to answer "is there anything free on Tuesday afternoon" is a failed screen, and you only find that out by standing behind the person using it during a busy morning.
This is why the discovery line item sits at the top of the table rather than being folded into the build. It is not optional overhead. Measured against the cost of rebuilding a core flow after launch, it is the cheapest money in the project.
What we deliberately did not build
The savings in a product like this come from the things you refuse, and refusing well requires knowing why.
- No native mobile apps. Denti360 is a responsive web application. Clinic staff work at a desk with a screen in front of them. Adding iOS and Android alongside web swings a project total by thirty to fifty percent, and it would have bought us almost nothing here.
- No imaging or clinical device integration. Connecting to X-ray and intraoral systems is a real request and a specialist project. It belongs in its own build, costed on its own terms, not folded into v1 as a bullet point.
- No insurance claim automation. Claims processing is a product in its own right, and it varies by market so heavily that building it early mostly means building it wrong.
- No custom reporting builder. A short list of fixed reports that answer the questions owners actually ask beats a query builder that answers every question badly and costs several times as much.
The compliance line deserves a sentence of its own, because it is the item most likely to differ for your build. Regulatory scope is set by the market a product serves, and it moves a healthcare build between tiers faster than any feature does. A version of this product sold into the United States would carry HIPAA obligations, BAA-eligible infrastructure and audit logging as first-class requirements from day one, and our healthcare cost guide prices what that adds. Do not copy a compliance budget from a product built for a different jurisdiction, including this one.
The cost that never stops
Every build cost article stops at launch. Launch is where the interesting part starts.
A live SaaS with paying clinics on it has running costs in four buckets: hosting and backups, third-party services, support, and the maintenance nobody schedules. The first two are small and predictable for a product at this scale. The third and fourth are neither.
Support is the one founders systematically underprice. It does not scale with the number of clinics, it scales with how many of them are new. A clinic in its first month asks questions constantly. The same clinic in month six barely contacts you. That means support cost tracks your growth rate rather than your customer count, which is exactly backwards from how most people budget it.
Maintenance is the other one. Dependencies age, browsers change, a payment provider deprecates an API version, and a report someone runs once a quarter turns out to have been wrong since March. None of this is on a roadmap. All of it consumes engineering time. Treating it as a fixed monthly allocation rather than an interruption is the difference between a product that stays healthy and one that quietly rots while everyone works on features.
The useful planning number: assume ongoing engineering of fifteen to twenty percent of the original build cost per year to keep a product like this current, before any new features. If that sounds high, it is roughly what one experienced developer costs for a few days a month, which is what it actually takes.
Three things worth sequencing differently
Running our own product changed the order we now recommend building one. Three items move earlier than instinct suggests.
Settle the reporting vocabulary before building the features. Dashboards are usually scheduled last, which means appointments, records and billing each decide independently what a "completed treatment" is, and reconciling those definitions afterwards is far more work than agreeing them upfront. Naming the handful of nouns the whole product reports on is a one-day conversation that repays itself for the life of the product.
Build the boring internal tooling earlier than feels justified. Admin and onboarding tooling is easy to defer because no customer ever sees it, and that is exactly why it gets deferred past the point where it hurts. Every manual step in onboarding a new account is a tax on growth, paid in someone's afternoon, forever. It converts directly into support hours, which are the most expensive engineering hours there are.
Talk to the front desk before the owner. The person who signs the contract and the person who determines whether the software survives contact with a real Monday morning are usually not the same person. Discovery that only involves the buyer produces a product the buyer likes and the staff route around.
What this means if you are pricing a similar build
Four things to take from this if you are holding a quote or writing a brief.
Ask where multi-tenancy lives in the plan. If it is in phase two, the quote is not comparable to one that puts it in week one. You are being quoted for two different products.
Ask what happens to billing edge cases. Part payments, refunds, discounts, plan changes mid-treatment. A vendor who has built billing before will answer immediately. A vendor who has not will say it is straightforward.
Price the year after launch, not just the launch. A build quote with no maintenance conversation attached is half a proposal.
Be suspicious of range-only answers, including ours. A range is a starting point. The reason we publish tier tables, feature tables and worked examples across our SaaS, MVP and healthcare cost guides is that a range on its own tells you nothing except that someone wants you on a call.
If you want a real number rather than a band, that is what our Scoping Sprint is for: $2,300 fixed, two weeks, ending with a clickable prototype, a technical plan and a fixed quote for the build, credited in full if we build it together. It is the only figure on this page that is a price rather than an estimate.
And if you are building in this space specifically, our healthcare software development page covers how we approach it, and SaaS development covers the multi-tenant machinery underneath. Denti360 is the version of that work where we were our own client, which is a uniquely unforgiving way to find out whether your estimates were any good.
