Six layers of the platform
Three domains are ours and stay the same. For every new client, we add subdomains on their domain — so the platform grows with every clinic we onboard.
Landing Page
amiro.healthOur public marketing site. Explains Amiro's value proposition, features, and how clinics can get started. No authentication, no patient data — purely informational.
But is the next visit booked?
rebook after results
into the next visit
tracked & proven
Demo Generator
demo.amiro.healthAn interactive sales tool we use to show prospects what Amiro would look like for their clinic. Each demo is branded with the prospect's name, colors, and real-looking data — a compact version of the full product experience. Think of it as a personalized walkthrough: results portal, staff tasks, follow-up workflows — all in a few key screens.
Internal Admin
admin.amiro.healthOur internal tool for managing all clients. Only accessible by the Amiro team. We use this to onboard clinics, manage people, assign roles, and monitor activity across all deployments.
Dashboard
Patient Results Portal
results.client.comA mobile-friendly page where patients access their lab results, prescriptions, and documents via a secure link (sent by SMS, email, or WhatsApp). Fully branded as the clinic — patients never see Amiro. No app download required.
Staff Dashboard
amiro.client.comWhere clinic employees log in to see their daily tasks, patient follow-ups, and operations queue. Fully branded as the clinic — only a small "Powered by Amiro" in the footer. Each person sees only what their role allows.
Staff Portals
amiro.client.com/p/...Unlike the full Staff Dashboard (which requires login and shows everything), portals are token-based micro-views — each one scoped to a single piece of work or a specific context. A staff member gets a link, opens it, and sees exactly what they need. No login, no navigation, no distraction. Think of them as focused windows into the system.
Overdue invoice action
Document review & send
Patient check-in status
Daily summary board
How it maps per client
When we onboard a new clinic, we ask them to set up subdomains and DNS records pointing to our servers. Everything else is configured on our side.
amiro.curitt.health
+ MX records for email
Integrate EMR
Roles & workflows
DNS records per client
The client needs to add these records to their domain. We handle the rest.
| Type | Record | Points to | Purpose |
|---|---|---|---|
| CNAME | results.curitt.health | app.amiro.health | Patient results portal |
| CNAME | amiro.curitt.health | app.amiro.health | Staff dashboard |
| MX | notifications.curitt.health | mail.amiro.health | Bounce handling & reply routing for outbound emails |
| TXT | notifications.curitt.health | SPF / DKIM / DMARC | Email authentication & deliverability |
notifications.curitt.health, so patients see the clinic's domain, not ours. This gives us full control over deliverability, sending speed, templates, and retry logic — while the clinic benefits from trusted, branded communication without touching their own mail setup.
Example: Curitt.Health deployment
Here's how all the domains look for our first client.
| Domain | What it is | Who sees it | Auth |
|---|---|---|---|
| amiro.health | Landing page | Everyone | None |
| demo.amiro.health | Demo generator | Prospects Via shared link | None (public link) |
| admin.amiro.health | Internal admin | Us Amiro team | Login (JWT) |
| results.curitt.health | Patient results portal | Patients Via secure link | Token in URL |
| amiro.curitt.health | Staff dashboard | Staff Clinic employees | Login (role-based) |
| amiro.curitt.health/p/... | Staff portals | Staff Via token link | Token in URL |
| notifications.curitt.health | Email sending | Patients Via inbox | SPF / DKIM |