DMEDesk / Acme, from launch to daily use.Operator console · Design only
DMEDesk / tenant detail

Acme, from launch to daily use.

Run the SaaS business without stepping into a customer’s patient records.

Synthetic account data

Acme DME

t_acme_demo · acme-preview · Fictional customer account

Open shop design preview ↗
Proposed Core plan$499Per month · Not activated
Named team seats3 / 15Admin / staff / driver
Locations1 / 1Fictional main warehouse
Standard launch$999One-time thesis · Not invoiced

Launch readiness · 2 / 6 gates

Pre-launch review
  1. ✓
    Company profile reviewed

    Fictional identity, one location and hospice-first workflow defined.

  2. ✓
    Active-record mapping prepared

    Source IDs and versioned CSV templates chosen.

  3. 3
    Clean import rerun required

    246 valid rows · 3 rejected rows · 0 changes applied.

  4. 4
    Owner sign-off pending

    Review reconciliation counts, active rentals and open orders before cutover.

  5. 5
    BAA / subprocessors require review

    No customer PHI ingestion before the required agreements are in place.

  6. 6
    Access and working-day test pending

    Admin MFA, roles, delivery/POD, maintenance release and invoice review.

Open fictional import walkthrough →

Seat usage · Fictional memberships

Shop team preview →
MemberTenant roleCounts toward 15 seatsOperator role
Alex KimShop adminYesNone
Robin LaneStaffYesNone
Sam PatelDriverYesNone
Platform boundary

This public prototype grants no administrative authority. A real console needs separate operator roles, enforced MFA, server-side authorization and audited support access. Shop admins must never inherit platform permissions; customer PHI stays out of sales and billing views.