dearbrightly.comDear Brightly: Telehealth Platform Engineering
A custom NestJS platform for a teledermatology brand. Built modular. Run by one team.
Failing prescription syncs, manual order rescues, a Retool ops patchwork. replaced by a purpose-built platform designed for reliability, operational clarity, and long-term extensibility.
A licensed teledermatology brand
Dear Brightly offers prescription-strength skincare through online consultation. Patients submit a structured skin profile, are evaluated by board-certified dermatologists, and receive ongoing care through a built-in provider chat experience.
Recognition: 2024 Beauty Innovation Award · NYT · Well+Good · The Cut · TechCrunch
The team was firefighting its own platform.
Five decisions that shaped the rebuild.
- 01
One language, one runtime.
Consolidate backend systems into a single TypeScript-based platform.
- 02
Modular monolith architecture.
Domain-bounded modules with clear ownership, unified deployment, and transactional consistency.
- 03
Decouple external dependencies.
Move third-party systems behind isolated, retry-safe background workflows.
- 04
Operational self-service.
Replace engineering-dependent workflows with internal tools and dashboards.
- 05
Zero-downtime migration.
Rebuild the system while safely migrating all existing data and users.
Build for clarity. Optimize for replaceability.
Modular monolith over microservices
Reduced operational overhead and preserved transactional consistency across business domains. Each module encapsulates its own state and logic. One runtime, one deploy.
Single unified runtime
Eliminated cross-language fragmentation and integration complexity. TypeScript end-to-end with shared schemas between backend and internal tools.
Asynchronous external workflows
Third-party systems live behind isolated, retry-safe background workers so user-facing operations stay fast and resilient under variable load.
Business-aligned domain modeling
Modules map to real operational domains (prescriptions, subscriptions, fulfillment, clinical), not technical layers. The system shape matches how the business actually runs.
Strict integration boundaries
External providers sit behind replaceable interfaces. Edge-case provider behavior stays contained instead of leaking into the rest of the platform.
The stack we shipped on.
| Layer | Stack |
|---|---|
| Backend | NestJS · TypeScript · GraphQL |
| Data | PostgreSQL · Redis · Queue workers · Object storage |
| Payments | Stripe |
| Clinical | External e-prescribing provider |
| Fulfillment | Multiple shipping and pharmacy partners |
| Tax · Email · Tracking | Tax automation · Email delivery · Attribution |
| Infra | Docker · CI/CD pipelines · Cloud infrastructure |
Eight modules. One runtime.
Subscription system
Custom subscription engine. Trial → active → paused → cancelled lifecycle, configurable renewal and retry behavior, pre-renewal notifications, safe state transitions without data loss.
Prescription pipeline
Idempotent processing of external prescription events. Order gating on validation, full traceability between prescriptions and fulfilled items, observability across every external interaction.
Clinical workflow engine
State-based visit lifecycle. Dynamic questionnaires, provider review and approval workflows, automated patient reminders for incomplete steps, configurable clinical review flags.
Fulfillment system
Multi-channel fulfillment with a unified order view. Rule-driven routing per product category, reconciliation of order states across systems.
Provider payout system
Marketplace-style compensation for clinical work. Automated payouts on completed visits, licensing-aware eligibility, geographic and regulatory routing of clinical assignments.
Promotion engine
Campaign-aware promotions with attribution tracking, differentiated order flows, and clean separation of promotional vs subscription metrics.
Admin platform
One internal dashboard replaces three. Refunds, reorders, replacements, subscription management, clinical oversight, promotion configuration. Operations execute without filing an engineering ticket.
Migration system
Full-platform migration of 60,000+ users with orders, subscriptions, prescriptions, clinical data, and support history. Idempotent, batch-safe, validated and reconciled across systems.
What we optimized for.
The architecture deliberately optimized for operational simplicity, consistency, and delivery speed over theoretical scalability extremes.
- Modular monolith over distributed services: less independent deploy flexibility, far less operational surface to babysit.
- Unified data model: better consistency, demands discipline on module boundaries.
- GraphQL-based API: accelerates internal development, adds schema governance overhead.
- Heavy async workflows: improves resilience, raises the bar on observability and retry handling.
- Strict abstraction of external systems: better replaceability, requires per-provider edge-case handling.
- Strong typing across systems: fewer runtime bugs, coordination cost during schema evolution.
Stability today. Headroom for tomorrow.
Infrastructure
- ~72% reduction in infrastructure cost
- Two backend stacks consolidated into a single platform
Reliability
- External system failures isolated from the user experience
- Manual operational intervention on prescription + fulfillment dropped sharply
- Improved observability across critical workflows
Operations
- Routine workflows moved from engineering-dependent to self-serve
- Unified operational tooling across clinical, commerce, and support
- Less fragmentation across teams
Migration
- 60,000+ users migrated with full historical operational data
- Safe cutover from legacy systems with validation + reconciliation safeguards
Platform velocity
- Faster iteration through unified architecture and shared types
- New features ship as modular extensions, not cross-system rewrites
Fragmented firefighting to unified platform.
The platform evolved from a fragmented system requiring constant operational intervention into a unified architecture designed for resilience, clarity, and extensibility.
Core workflows now operate reliably under load, external dependencies are isolated from user experience, and operational teams execute independently without engineering bottlenecks.
The result is a system that supports both stability today and controlled expansion over time.
Custom commerce + AI for DTC health
How we approach builds in this space, beyond just Dear Brightly.
Vendure Commerce
The commerce service behind Dear Brightly. A Shopify alternative for state-machine checkouts.
SirenAI: AI Booking Platform
Another rebuild: multi-tenant SaaS, AI agents on WhatsApp + SMS + Telegram.
Building something similar?
Systems where commerce, clinical workflows, and operations have to work as one platform, that's what we ship. Start a conversation; we'll tell you honestly whether we're the right fit.