Your brand. Your domain. Our platform underneath.
Run a complete medical field-operations platform under your own identity — logo, colours, typography, domain and sign-in — with strict isolation between every customer. One codebase, configured per tenant, never forked.
It looks, feels and reads like your product
- Your logo, colours and typography across every surface
- Light and dark treatments handled from one token set
- Branded email, web push and PWA install experience
- Tone of voice and terminology configurable per tenant
Your own domain and a branded sign-in
- Bring your own domain with managed TLS
- Connect your identity provider for staff sign-in
- Branded sign-in for surgeons and reps
- Tenant resolved from the session, every request
Per-tenant feature flags and role model
- Feature flags scoped to each tenant
- Roles and permissions tailored per customer
- Expand a tenant’s footprint without redeploying
- New capabilities reach every tenant at once
Isolation enforced where it can’t be bypassed
Multi-tenancy is only safe if separation is structural. Every tenant-scoped table carries a tenant ID and a row-level security policy enforced by the database. The tenant context comes from the authenticated session — never a URL or request body — so a query simply cannot reach another tenant’s rows, even by mistake.
- Row-level security on every tenant-scoped table
- Tenant context derived from the session, not the request
- Cross-tenant access restricted to break-glass admins and audited
- Service-to-service calls authenticated by managed identity only
- Every sensitive action written to an immutable audit trail
Configuration, not forks
Bespoke branches age, drift and rot. Every MedRep tenant runs the same codebase, so a fix or a feature lands for everyone — and your deployment never falls behind.
No per-customer branches
Differences live in config tables and feature flags — never in code. There is nothing to fork and nothing to merge back.
One upgrade path
Improvements, security patches and new modules ship to every tenant on the same release. No customer is stranded on an old build.
Predictable to operate
One thing to test, monitor and harden. Reliability compounds because every tenant exercises the same path.
How a deployment comes together
A new tenant is a guided configuration, not an engineering project. Five steps from kick-off to a branded environment your team can log into.
- 01
Brand and theme
We load your logo, colour palette, typography and tone of voice as theme tokens. The whole product — admin console and field PWA — restyles instantly. No design forks, no CSS overrides.
- 02
Domain and sign-in
Map your own domain and a branded sign-in. Surgeons, reps and head office authenticate against your identity provider. Your customers never see the word “MedRep”.
- 03
Modules and roles
Turn on the modules that tenant needs — CRM, catalogue, inventory, training, events, AI — and shape the role model: who sees what, who can do what, per tenant.
- 04
Data and migration
Seed catalogue, team and reference data into the tenant’s isolated partition. Every row is stamped with a tenant ID before it ever touches the database.
- 05
Go live
Smoke-test against the eight golden journeys, flip the domain live and hand over the admin console. Most tenants launch in weeks, not quarters.
Global reach, regional control
- Choose the Azure region per tenant
- Data residency for regulated markets
- Paired-region backups for resilience
- Multi-region deployment for global teams
White-label, answered
One platform. Every tenant runs on exactly the same codebase and the same deployment. What differs is configuration — theme tokens, feature flags, role models and seeded data — held in the database, not in branches. That is what lets us ship improvements to everyone at once.
Every tenant-scoped table carries a tenant ID and a row-level security policy enforced by the database itself. The tenant context is derived from the authenticated session on every request — never from a URL or request body — so a user simply cannot read or write outside their own tenant, even if a query tried to.
Yes. Feature flags and the role model are per tenant. One customer can run the full suite while another starts with CRM and catalogue and expands later. Switching a module on is a configuration change, not a release.
It lives on your domain with your branding. You can connect your own identity provider for staff and offer branded email-and-password for field users. The hosted experience carries your logo and colours throughout.
Because it is configuration rather than a bespoke build, a typical tenant moves from kick-off to a branded, populated environment in a matter of weeks. The longest pole is usually preparing your own catalogue and reference data, which we help you import.
On Microsoft Azure, in the region you choose, with paired-region backups. Multi-region deployment is available for customers with data-residency or latency requirements across markets.
Launch your platform under your own brand
See MedRep themed for your identity, on your domain, with your modules switched on — a working environment, not slideware.