DentalPro.cloud: a practice platform built around the tooth chart
Cloud dental practice management on Firebase and Google Cloud — multi-tenant clinics, per-tooth clinical records, WhatsApp patient communication and AI-assisted documentation.
Built with SmartDocx AI Systems Private Limited, a healthcare technology venture co-founded by GegoSoft's founder.
- SECTOR
- Dental / Clinical SaaS
- MODEL
- Multi-tenant SaaS
- TEAM
- 4 members
- SCOPE
- Product and go-to-market
- STATUS
- Private Beta
Why general practice software fails in a dental clinic
Most clinical software organises records by encounter. A patient visits, a note is written, the note joins a chronological list. For general practice that works, because the unit of care is the visit.
Dentistry does not work that way. The unit of care is the tooth. A dentist needs to know the entire history of the upper right second molar — every filling, every surface treated, when the crown was placed, which surfaces have decayed since — and needs it visually, arranged the way the mouth is arranged. A chronological note list cannot answer that question without reading every entry.
Get the chart wrong and no amount of scheduling, billing or reporting rescues the product.
So the odontogram came first and everything else was built around it. Appointments, treatment plans, billing and clinical notes all attach to chart entries rather than existing as parallel record sets that happen to share a patient name.
What makes dental charting hard to build
Teeth have surfaces
A record is not "tooth 16 has a filling." It is which surfaces of tooth 16 were treated, when, and with what — several addressable positions per tooth, each with its own history.
Dentition changes
Children have primary teeth that are progressively replaced. The chart has to represent mixed dentition and carry history across the transition rather than starting over.
Numbering systems differ
FDI, Universal and Palmer notations are used in different regions. The stored data has to be notation-independent so the display can change without the record changing.
State is temporal
"Current condition" is a view over a history, not a stored value. What the chart shows today must be reconstructible for any earlier date.
Input happens chairside
The dentist is gloved, mid-procedure, working on a tablet. Interaction has to survive that, which rules out dense forms.
Serving a solo dentist and a growing group from one platform
Dental practice is unusually fragmented. A large share of clinics are one or two dentists with a receptionist and an assistant. Software priced and architected for hospital groups does not reach them, and software built only for solo practitioners breaks the moment a practice opens a second location.
The platform is multi-tenant, so each clinic's data is isolated while running on shared infrastructure — which is what makes a price point workable for a single dentist. Role-based access covers the same range: in a small clinic one person may hold several roles, while a larger practice separates reception, clinical, and administrative permissions across a bigger team.
Where AI earns its place
Two features, both aimed at the same thing: reducing the time a dentist spends typing rather than treating.
Both are framed as assistance rather than automation, in the product and in the interface. A scribe output is a draft the dentist confirms. An imaging flag is a prompt to look, not a finding. That framing is a clinical safety decision before it is a product one.
Designed for India's DPDP framework
The Digital Personal Data Protection Act, 2023 became operational when its Rules were notified in November 2025, with full enforcement from 13 May 2027. Every dental clinic in India holding patient records is inside that window now.
The distinction that matters commercially: under DPDP the clinic is the Data Fiduciary and carries the obligations. The platform is a Data Processor. A clinic cannot outsource accountability to its software — but it also cannot meet the obligations if the software makes them impossible. We built DentalPro.cloud so the software side is not the blocker.
Purpose limitation
Role-based access restricts patient data to staff whose function requires it, rather than granting whole-clinic visibility by default.
Tenant isolation
Each clinic's records are separated at the data layer, so one practice's patient data is never reachable from another tenant.
We describe this as alignment rather than compliance, deliberately. DPDP compliance is a property of an organisation and its practices, not a certificate a software vendor can issue. What a platform can do is make the clinic's obligations achievable instead of impossible, and that is what we designed for.
What the platform covers
Technology choices and why
A different stack from our other healthcare work, chosen for a product that had to reach small clinics economically.
Angular
The odontogram is a large, stateful, heavily interactive component. Angular's structure and typing suited a view of that complexity better than a lighter framework would.
Firebase
Real-time sync between reception and chairside, with authentication and per-tenant security rules handled at the platform level rather than rebuilt.
Google Cloud
Scales down as well as up, which matters when the tenant base is many small clinics rather than a few large ones.
Express.js
Handles the work that does not belong in the client: integrations, AI service calls, scheduled jobs and messaging.
Flutter
One codebase across Android and iOS for practitioner access, maintained by the same small team.
Patient reminders on the channel patients actually read, which reduces missed appointments more reliably than email.
The work that happened after the software
A SaaS product that nobody finds is not a product. Our involvement extended past engineering into the commercial layer, which is unusual for a development engagement and worth being explicit about.
Designed and built the marketing site, including how the product is explained to dentists rather than to buyers of software.
Connected enquiry capture to a CRM so trials and demo requests entered a tracked pipeline instead of an inbox.
Structured the site around what dentists search for when their current software frustrates them.
Ran acquisition campaigns targeting practice owners, feeding the same tracked pipeline.
How the team built it
Four people covering product, engineering, mobile and go-to-market. GegoSoft engineers use Claude Code as standard daily tooling, and on a team this size the effect is most visible in coverage: it makes it practical for a small team to maintain an Angular web application, an Express service layer, Firebase security rules and a Flutter application at once.
Clinical workflow decisions, the chart data model and every AI safety framing choice were made by the team, and all code passed normal review before merge.
Common questions
Can GegoSoft build dental or clinical software for us?
Yes. We build clinical platforms from scratch and have shipped several, including dental practice management, EMR, hospital management and pharmacy systems. The first step is understanding how your clinical workflow differs from what already exists.
Why is dental charting harder than it looks?
Clinical history attaches to individual tooth surfaces rather than to visits, dentition changes as patients grow, notation systems differ by region, and the chart must be reconstructible for any past date. That combination is what most general-purpose clinical software cannot represent.
Does the AI make diagnoses?
No. The scribe produces draft documentation the dentist reviews and confirms, and imaging analysis surfaces areas for attention rather than issuing findings. Clinical judgement stays with the practitioner, by design.
Can a single-dentist practice use a multi-tenant platform?
Yes, and that was a design goal. Shared infrastructure with isolated tenant data is what makes the economics work for a small clinic while still supporting practices that later open additional locations.
Is DentalPro.cloud DPDP compliant?
DPDP compliance belongs to the clinic, which is the Data Fiduciary under the Act, not to the software vendor. What we can say is that the platform is built so the clinic's obligations are achievable: role-based access limits who sees patient data, tenant isolation separates practices, and the data model supports the record-keeping the Act expects. Full enforcement begins 13 May 2027, so this is worth raising with any software vendor now.
Does GegoSoft handle marketing as well as development?
For product engagements, often yes. On DentalPro.cloud we built the product website, integrated the CRM, handled on-page SEO and ran acquisition campaigns. We scope this separately from engineering.
Related work
Clinical records with a clinician-controlled AI assistant.
HEALTHCARE Hospital management and bookingMulti-location scheduling for consultations and diagnostic resources.
SERVICES SaaS product developmentMulti-tenant architecture, subscription models and go-to-market.
Building clinical software?
Tell us what your clinical workflow looks like and where existing software fails it. We have built dental, EMR, hospital and pharmacy platforms, and we will tell you honestly which parts are solved problems and which are not.
Start a conversation See all case studies