Dental lab software that follows every case from prescription to invoice.

Dental lab management software runs the production side of a dental lab. It takes a case from the moment a dentist sends a prescription to the day the lab sends the invoice, keeping the prescription, shade, material, scan files, production stage, due date, and cost in one record. It covers case intake, the production board, the dentist portal, price lists, invoicing, and remake tracking. It is not practice software: it does not run the clinic, see patients, or manage appointments.

Practice software runs the clinic: appointments, patient records, charting, and billing the patient. Lab management software runs the lab: the prescription the clinic sends, the restoration the lab makes, the stages it passes through, and the invoice the lab sends the clinic. A lab that serves many clinics needs the lab side. The two systems can share information where the connection exists, but one does not replace the other.

Every case gets one record at intake, and everything about that case attaches to it: the digital prescription, the scan files, the photos, the shade, the messages, the stage, the due date, and the invoice. The record moves through the same stages for every case, from intake to design, production, quality check, and delivery. When a dentist sends a second file or a correction, it lands on the same record as a new version instead of starting a second case or a separate chat thread.

The case stops at intake instead of reaching the bench. The prescription form asks for the fields a technician needs before starting: tooth, restoration type, material, shade, margin, and the files. If something is missing, the dentist sees exactly what is missing and the lab asks the question before any work begins. Starting on an incomplete prescription is how most remakes begin, so the check happens before fabrication, not after the case comes back.

A remake stays on the original case record, with the reason, whether it is a full or partial remake, and whether the clinic or the lab pays for it, decided and recorded before the case moves again. The history stays attached to the original prescription and the original stage timeline, so the lab can see patterns: which clinics, which materials, and which missing details keep coming back. A remake without a recorded reason is lost money nobody can explain next month.

That depends on the scanners and the file types your clinics send. The common route is a scanner inbox that accepts order files and notification emails from the main scanner systems, including 3Shape Communicate and Medit Link, and a built-in viewer for STL, PLY, OBJ, and DICOM files so the lab can inspect a scan without opening another program. We confirm which scanners your clinics use during scoping and test the intake against real files before the first release.

Yes, through a dentist portal. Each clinic gets its own login to send a digital prescription, upload scans and photos, answer a question on a case, and see where each of their cases stands and when it is due. The portal shows status, not the lab's internal notes or costing. The point is simple: the dentist stops phoning for status updates, and the lab stops interrupting technicians to answer them.

Materials and time are recorded against the case as the work happens, so the cost of a case is the materials used, the time spent, and the price list that applies to that clinic. The lab can see which cases earn their price and which do not, instead of finding out at month end. Price lists are set per clinic, invoices are generated from completed cases, and payments are tracked against the invoice.

Physical impressions still arrive, and the system has to handle both. A physical case gets the same record as a digital one, with the impression logged at reception, a barcode or case number tying the physical work to the record, and the same stages, due date, and invoice. The difference is only at intake: a scan file arrives through the portal or scanner inbox, while a physical impression is booked in by the front desk. After intake, both follow the same path.

The first paid phase may cover a bounded audit, a proof of concept, a recovery plan, or a small first release. The final price depends on how deep the case flow goes, how many clinics and lab staff it serves, what it needs to connect to, whether data needs moving over, whether phones or tablets are involved, and the condition of existing code. The agreed phase is priced in writing before it starts.

Buy an existing lab system when it handles your case flow with reasonable setup: intake, production tracking, dentist portal, price lists, and invoicing. Several maintained lab systems cover exactly that, and a small lab with standard work should start there. Build custom when your workflow breaks the template: remake rules and billing that follow how your lab actually charges, costing tied to your materials and price lists, a portal your clinics will actually use, or connections to systems the maintained products do not cover. If your case flow is standard, buying is the better trade.

You judge what you can see, not the code. Every checkpoint is working software you click through yourself, tested against the case flow agreed at the start: a prescription arrives, the case moves through the stages, the dentist sees the status, the invoice matches the work. Progress is reported in plain language: what changed, what's next, and what it costs. Because you own the code, the accounts, and the operating notes throughout, nothing about the work is locked inside our heads. Our job is to make the work checkable; your job is to check it against your lab.

Timing depends on scope: a bounded audit or proof of concept is a smaller engagement, while a system with several connections to other systems, data to move over, mobile apps, or formal compliance controls takes longer. The schedule is set once the first case flow and what 'done' looks like are clear.

Yes. Takeover is a common first engagement, and it always starts with an audit: where the code lives, how your data is organized, what is tested, which outside services it depends on, who can access what, and how updates go live. Code that is understandable and fit for the next release stays; only the parts blocking reliability get replaced. And if you already paid another vendor and have nothing working, the audit tells you which story you have before you spend more: the most expensive version is the product that looks finished, clean screens and clicking buttons, while underneath nothing is tested and the security checks run in the browser, where anyone can tamper with them, instead of on the server where they hold.

We need one person who owns the case flow, access to the relevant users and systems, timely answers on lab rules, and someone who can accept or reject each milestone. A weekly working session is usually enough once the scope is stable. Your team should not have to manage developers day to day. The team that scopes your project is the team that does the work: no handoff to another vendor after you sign, and you can talk to the people doing the work directly.

You own the code built for you and control where it lives, the cloud accounts, the data, analytics, and third-party subscriptions. Outside services and open-source pieces keep their own licence terms. The operating notes and handover material stay current so another capable team can take over.

Every launch includes post-launch warranty cover for defects in the agreed scope, release support, and small screen corrections. After that, work can continue as another fixed phase or an ongoing product engagement. The code and accounts stay under your control either way.