Platform Engineering8 min read

The Preset Pattern: Ship Entire Verticals, Not Features

Features are building blocks; presets are complete, deployable configurations for specific verticals. A preset bundles entity schemas, workflows, UI layouts, roles, and automation into a single package that deploys in 48 hours.

THB Engineering
January 26, 2026
presetsvertical SaaSconfigurationdeployment

The Preset Pattern: Ship Entire Verticals, Not Features

Software platforms ship features. A new field type, an integration connector, a reporting widget. Each feature is a building block -- useful in the abstract, useless until someone assembles them into a working system. In healthcare IT, that assembly is where the real cost lives.

A hospital that buys a CRM platform does not need "custom fields" and "workflow automation" and "role-based access control" as separate capabilities. It needs a patient relationship management system — with the right entities pre-defined, the right workflows pre-configured, the right roles pre-assigned, and the right UI layouts pre-composed. The gap between a feature set and a deployable solution is weeks or months of implementation work, and it is that gap that makes healthcare software deployments slow, expensive, and fragile.

The preset pattern closes that gap. A preset is not a template. It is not a starter kit. It is a complete, deployable vertical configuration that defines everything a specific use case needs — entity schemas, workflow rules, UI compositions, role hierarchies, automation triggers, and integration mappings — in a single, versioned package.

The Feature Trap

Feature-based platforms succeed in demos and fail in deployment. The sales team shows an impressive set of capabilities. The implementation team then spends months wiring those capabilities together for each client's specific use case.

Every deployment is a custom project. Client A needs a patient CRM. Client B needs a pharma field operations CRM. Both use the same platform, but their entity models, workflows, and role structures are entirely different. The implementation team builds each from scratch — defining schemas, configuring workflows, composing UI screens, setting up roles. By the time the system is live, months have passed and the implementation has become a bespoke project with bespoke maintenance requirements.

Knowledge does not transfer. The implementation team learns how to configure a patient CRM for Client A. When Client C needs a similar patient CRM, the knowledge from Client A's implementation is trapped in configuration artifacts and implementation notes. The team rebuilds rather than reuses, because there is no structured mechanism for packaging a deployment as a reusable artifact.

Upgrades break configurations. When the platform ships a new version, each client's custom configuration must be validated against the new release. With 50 clients running 50 unique configurations, every platform upgrade becomes a compatibility testing project. The cost of moving forward compounds until clients are locked into old versions.

Deployment timelines make sales cycles painful. A sales team that promises a 90-day implementation but delivers in 180 days has a credibility problem. When deployment timelines are unpredictable — because every deployment is a unique assembly — sales cannot make reliable commitments and customers lose confidence.

Why Features Alone Are Not Enough

The gap between a feature set and a deployable solution is where healthcare implementations fail

🧩

Assembly Required

Features are building blocks. Every deployment requires weeks of custom assembly — schema design, workflow configuration, UI composition, role setup.

🔄

Non-Transferable Knowledge

Implementation expertise is trapped in per-client artifacts. Similar deployments are rebuilt from scratch instead of replicated.

🔗

Upgrade Fragility

Each custom configuration must be individually validated against platform updates. 50 clients means 50 compatibility tests per release.

📅

Unpredictable Timelines

Custom assembly makes deployment timelines variable. A 90-day estimate becomes 180 days, eroding customer and sales team confidence.

Anatomy of a Preset

A preset is a structured, versioned package that contains everything needed to instantiate a specific vertical use case on the platform. It is not documentation or guidance — it is executable configuration.

Entity Schemas

The preset defines the complete data model for its use case. A Hospital CRM preset might define:

  • Patient entity with demographic fields, insurance information, clinical identifiers, consent status, and risk stratification markers
  • Encounter entity with visit type, admission/discharge timestamps, provider assignments, diagnosis codes, and disposition
  • Referral entity with referring provider, receiving provider, referral reason, authorization status, and completion tracking
  • Care Gap entity with protocol reference, patient cohort, gap status, intervention assignments, and closure evidence

Every field, every relationship, every validation rule is specified in the preset. When the preset is deployed, the schema engine creates these entities with their full structure. No implementation engineer needs to design a patient data model — it ships ready.

Workflow Definitions

The preset includes pre-configured workflows for its vertical:

  • Patient intake — registration, insurance verification, consent collection, initial assessment routing
  • Referral management — referral creation, authorization tracking, scheduling, specialist communication, completion acknowledgment
  • Discharge process — order verification, summary generation, follow-up scheduling, patient education, care gap evaluation
  • Care gap activation — cohort identification, outreach assignment, attempt tracking, closure documentation

Each workflow is a sequence of configurable steps with conditions, assignments, escalation rules, and notification triggers. The implementation team does not build workflows — they review and adjust pre-built ones.

UI Compositions

The preset defines how screens are composed for its use case — which entities appear on which views, field ordering, card layouts, list columns, detail panel configurations, and dashboard widgets. A patient-facing CRM presents patient demographics prominently with encounter history and care gaps visible on the same screen. A pharma CRM presents territory and field force information with call planning and sample inventory on the primary view.

Role Hierarchies

Each preset ships with role definitions appropriate to its vertical. A Hospital CRM preset includes roles for front desk staff, nurses, care coordinators, physicians, quality directors, and administrators — each with appropriate entity access, field visibility, and action permissions pre-configured.

Automation Rules

Scheduled tasks, triggered actions, and event-driven automations are included in the preset. Morning brief generation, care gap re-evaluation, SLA escalation, appointment reminders — these are not features that need to be configured from scratch. They ship as part of the preset, ready to activate.

Preset Composition

A preset packages every configuration dimension into a single deployable artifact

Preset Package
Hospital CRM
Patient operations vertical
Pharma CRM
Field operations vertical
Sales CRM
Pipeline management vertical
Doctor CRM
Provider relations vertical
Configuration Dimensions
Entity Schemas
Data model definitions
Workflows
Process automation rules
UI Layouts
Screen compositions
Roles & Policies
Access control hierarchy
Platform Engine
Schema Engine
Dynamic entity management
Workflow Executor
Rule-based orchestration
UI Renderer
Config-driven composition
Policy Engine
RBAC enforcement
Shared Infrastructure
Multi-Tenant Data Layer
Isolated storage
API Gateway
Sub-millisecond routing
Intelligence Pipeline
AI and analytics

Preset Composition: Combining Verticals

Real-world deployments rarely fit a single preset perfectly. A large hospital chain might need:

  • Patient CRM capabilities for clinical operations
  • Doctor CRM capabilities for provider relationship management
  • B2B CRM capabilities for payor and vendor relationships

The preset pattern supports composition. Multiple presets can be layered onto the same tenant, combining their entity schemas, workflows, and role definitions into a unified configuration. The platform's schema engine resolves overlaps — a "Patient" entity that appears in both the Hospital CRM and Doctor CRM presets is merged, not duplicated.

Extending Presets

A preset is a starting point, not a ceiling. After deploying a Hospital CRM preset, the implementation team can:

  • Add fields to preset entities — a hospital-specific "bed management zone" field on the Encounter entity
  • Modify workflows — adjust the discharge process to include a step specific to the organization's quality reporting requirements
  • Create new entities — add a "Research Enrollment" entity that does not exist in any standard preset
  • Adjust roles — split the "Care Coordinator" role into "Inpatient Coordinator" and "Outpatient Coordinator" with different permissions

These extensions are layered on top of the preset, not embedded in it. When the preset is upgraded to a new version — adding new fields, improving workflow logic, fixing configuration errors — the extensions are preserved. The upgrade applies the preset's changes to the base layer while leaving the client's extensions intact.

Overriding Specific Settings

Sometimes a client needs to override a preset default rather than extend it. A pharma CRM preset might default the "Call Report" entity to require a signature field. A specific client's compliance team determines that digital acknowledgment is sufficient. The override replaces the signature requirement with an acknowledgment field — a targeted change to a single setting within the preset.

Overrides are tracked separately from the base preset. When the preset is upgraded, overrides are flagged for review — the implementation team can evaluate whether the override is still appropriate given the new preset version.

The 48-Hour Deployment

The preset pattern's most tangible benefit is deployment speed. When a new hospital needs a CRM:

  1. Select preset — Hospital CRM (or compose Hospital CRM + Doctor CRM) — immediate
  2. Provision tenant — create isolated namespace on shared infrastructure — automated, minutes
  3. Apply preset — entity schemas, workflows, UI layouts, roles, automation rules are instantiated — automated, minutes
  4. Configure specifics — organization name, branding, timezone, EMR integration endpoints — hours
  5. Customize extensions — add client-specific fields, adjust workflows, fine-tune roles — hours
  6. User setup and training — import staff, assign roles, train power users — hours

Total elapsed time: approximately 48 hours. Compare this to the 6-18 month timeline of feature-based deployments where every step above is performed from scratch.

The 48-hour timeline is not theoretical. It is achievable because the preset contains the accumulated knowledge of every previous deployment in that vertical. The hundredth hospital CRM deployment benefits from everything learned in the first ninety-nine — not through documentation, but through the preset itself.

Preset Economics

🚀

48-Hour Deployment

Pre-configured verticals eliminate months of custom assembly. New organizations go live in days, not quarters.

📦

Accumulated Knowledge

Each preset version encodes lessons from every previous deployment. The hundredth client benefits from the first ninety-nine.

🔄

Safe Upgrades

Preset updates apply to the base layer without disrupting client-specific extensions and overrides.

🎯

Predictable Scope

Sales and implementation teams can quote timelines with confidence because preset deployments follow a known, repeatable process.

Why This Matters for Healthcare

Healthcare IT has been trapped in a project-based delivery model for decades. Every implementation is a project. Every project has a timeline, a budget, a team, and a risk profile. The preset pattern converts healthcare IT delivery from a project model to a product model.

Smaller organizations get access. A 50-bed rural hospital cannot afford an 18-month CRM implementation. But it can afford a 48-hour preset deployment. The preset pattern democratizes access to enterprise-grade healthcare technology.

Deployment capacity scales. A team that can deploy one preset-based CRM in 48 hours can deploy 50 in a quarter. Growth is limited by market demand, not by implementation bandwidth.

Quality improves with volume. Every deployment surfaces configuration improvements that feed back into the preset. The preset gets better with every deployment — a compounding quality advantage that custom implementations cannot replicate.

Time-to-value collapses. A hospital that goes live in 48 hours starts realizing value in its first week. A hospital that waits 18 months for a custom implementation starts realizing value in its second year — if the implementation succeeds.

The Bottom Line

Features are necessary but not sufficient. The value of a platform is not its feature count -- it is how quickly those features become a working solution. The preset pattern packages that assembly into a reusable, upgradeable artifact.

Ship verticals, not features. The hospital does not care about your workflow engine. It cares about having a working discharge process on day one.


THB's CRM Suite ships with five industry presets — Hospital, Doctor, Pharma, Sales, and B2B — each deployable in 48 hours on the Application Engine. Presets are composable, extendable, and independently upgradeable. See the platform architecture.