Healthtech · United States

Scaling a dental analytics platform from 350 to more than 600 practices on a faster reporting pipeline

Elasticsearch-backed reporting, timezone-aware goal automation across hundreds of tenants, two-way sync with 75+ practice-management systems, role-specific dashboards and mobile APIs, inside a SOC 2 and HIPAA-compliant Rails product.

Client
Dental practice growth platform
Engagement
Embedded engineer
Period
2024 to present
  • 600+practices on the platform, up from 350
  • 75%faster goal report refreshes
  • 75+practice-management systems synced two-way
The product

What it is

A SOC 2 and HIPAA-compliant SaaS that sits on top of a dental practice's management system and turns the numbers into daily behaviour: live dashboards, monthly goals, leaderboards, team incentives paid out through Stripe, automated patient workflows and a morning huddle screen. It syncs two-way with more than 75 practice-management systems and is used by single practices, dental service organisations and consultants who manage many practices at once.

Where we came in

The platform was growing fast and the reporting layer hadn't kept up. Goal reports refreshed slowly because they aggregated straight from the transactional database. Monthly goals were set up by hand per practice, in each practice's own timezone. Consultants comparing dozens of practices had to click through dashboards to answer simple questions. The data ingestion from practice-management systems also needed to support instant onboarding for free trials. We joined the engineering team as a senior engineer owning reporting and ingestion.

What we owned

  • Reporting pipeline: Elasticsearch indexing, goal creation and refresh jobs, new goal types
  • Data ingestion from practice-management systems: initial, hourly and historical syncs
  • Role-specific dashboards for practices, doctors and hygienists, with Excel export
  • Mobile APIs for production, collections, treatment plans and analysis
  • Per-tenant scheduling so automation runs in each practice's local time
Architecture

How the system is layered, from the people using it down to the data and the services it depends on.

  1. 01Clients
    • Web app
    • Mobile app (via mobile APIs)
    • Consultant dashboards
    • Operatory huddle screen
  2. 02Application
    • Ruby on Rails monolith
    • Role-based dashboards
    • Goal engine
    • Incentive calculations
  3. 03Background jobs
    • Per-tenant cron scheduling
    • Goal creation at 1 AM local time
    • Hourly incremental syncs
    • Report refresh jobs
    • Six-month trial backfills
  4. 04Data
    • PostgreSQL
    • Elasticsearch indices
    • Per-tenant timezone rules
  5. 05Integrations
    • 75+ practice-management systems
    • Stripe (team payouts)
    • Google (reviews)
Engineering decisions

The choices that made the difference, and why we made them.

  1. 01

    Timezone-aware automation for hundreds of tenants

    Every practice gets its monthly goals created at 1 AM in its own timezone, by a cron job that walks tenants and schedules per-tenant execution rather than running once in UTC. The same pattern drives automated report refreshes, so a practice in Hawaii and one in Maine both start the month with fresh numbers at the right local time.

  2. 02

    Elasticsearch where it paid, and removed where it didn't

    We indexed goals, patients, treatments and ledger transactions into Elasticsearch to take the reporting load off PostgreSQL, which cut goal update latency by more than 75 percent. Later, once the biggest tables were costing more to keep in sync than they saved, we led a scoped removal from those tables. Good architecture includes knowing when to take something out.

  3. 03

    Ingestion that makes free trials useful on day one

    Cron-based pipelines pull practice data from multiple practice-management systems: a full initial load, hourly incremental updates, and a six-month historical pull during trials so a prospect sees real trends instead of an empty dashboard.

  4. 04

    Dashboards shaped by who is looking

    A practice owner, a doctor and a hygienist need different numbers from the same ledger. We built role-specific dashboards with their own goal types and leaderboards, an Excel export for consultants who compare dozens of practices, and the mobile APIs behind production, collections, treatment-plan and analysis screens, all reading from the same indexed data so no two views disagree.

Outcome
  • The platform grew from 350 to more than 600 practices on the same reporting pipeline.
  • Goal reports refresh more than 75 percent faster, so leaderboards and incentives reflect the day as it happens.
  • Consultants compare practices from one role-specific view and export to Excel instead of clicking through each dashboard.
  • Trial practices see six months of history on day one, which shortened the path from sign-up to paid.

Technology

  • Ruby on Rails
  • PostgreSQL
  • Elasticsearch
  • Docker
  • AWS
  • Stripe

Building something similar?

Tell us what you're building. You'll get a straight answer on scope, timeline and cost, usually within one business day.