Imagine this scenario.

You’re six months into building a multi-tenant healthcare platform. The situation:

• Ten paying customers
• Tenant onboarding takes weeks, not minutes
• Teams are inconsistent in how they ship software
• Every change requires SRE support with no self-service for teams
• Separate deployment patterns per tenant
• Slightly different compliance controls
• Custom integrations per customer
• Manual tweaks in production
• Confusing Kubernetes namespaces
• One-off Kafka topics
• SREs patching drift at 2 a.m.

Every new customer increase complexity non-linearly.

Every audit becomes a fire drill.

Every production incident requires tribal knowledge.

This is not a scaling problem.

This is a platform problem.

When we started building Hyphen — a siloed, multi-tenant healthcare platform with a mission to redefine the way the healthcare ecosystem collaborates — we made one decision early:

We would not build products on top of operational chaos.

Building a siloed, multi-tenant healthcare platform without foundational platform engineering principles was not an option for us. In our space, the cost of inconsistency is not just engineering pain — it’s compliance risk, audit failure, and operational fragility.

This post explains how we built Hyphen with platform engineering at its core — and the practical patterns you can apply immediately.

Why Healthcare Changes the Equation

Healthcare platforms are not typical SaaS systems.

We operate with:

• Strict tenant isolation requirements
• HITRUST-aligned controls
• Audit trails and traceability
• Real-time and batch connectors
• High availability requirements
• Customer-specific configurations

Our stack:

• AWS as the cloud foundation
• Kubernetes for workload orchestration
• Pulumi for infrastructure as code
• Kafka for event streaming
• Lakehouse architecture for analytics
• Kotlin services and React frontend

In a single-tenant startup, you can “figure out the platform later.”

In a regulated, siloed, multi-tenant healthcare environment, you cannot.

Platform engineering was not an optimization for us. It was a prerequisite.

How We Built the Hyphen Platform

Principle 1: Treat the Platform as a Product

We did not treat infrastructure as “DevOps support.”

We treated it as:

• A product with a roadmap
• A customer (internal and external engineering teams)

The goal was to reduce cognitive load, increase consistency, and standardize without slowing teams down.

This was enabled through our Internal Developer Portal, we call it the Hyphen Admin UI , which acts as a self-service layer over our infrastructure and deployment systems.

It standardizes how services are provisioned, deployed, and configured by encoding these workflows into reusable templates and guardrails, reducing cognitive load while eliminating inconsistency across teams.

Principle 2: Multi-Tenancy as a First-Class Abstraction

We decided early that tenant isolation would not be an afterthought.

We created a clear model for how our platform supports multi-tenancy. We did not manually configure it. We codified it.

Provisioning a new tenant became as simple as filling out a form and hitting submit.

Isolation, policies, infrastructure, and guardrails were applied automatically.

Principle 3: Golden Paths Over Freedom

Engineers don’t always want infinite flexibility. They want safe defaults.

We created opinionated templates and libraries that engineers could easily embed in their services.

Instead of telling engineers how to do things, we made the correct way the easiest way.

Principle 4: Infrastructure as Code Everywhere

The Hyphen Admin UI, with one of its capabilities being Infrastructure as Code, became our single source of truth for:

• EKS clusters
• IAM roles
• S3 policies
• Workload management
• Secrets management
• Database setup
• Kafka infrastructure
• Lakehouse permissions

We made minimal to no console-driven changes.

Our motto was simple:

If it wasn’t in code, it shouldn’t exist.

This gave us:

• Version control
• Reviewable changes
• Audit traceability
• Deterministic environments

What This Looks Like in Practice

Scenario: Onboarding a New Customer in Hyphen

Without platform engineering, onboarding a new customer would look like:

• Weeks of infrastructure provisioning in multiple environments
• Manual database setup
• Manual service deployment
• Manual configuration management
• IAM errors
• Manual compliance reviews
• Custom Kafka topic creation
• Drift between environments

With platform engineering and the Hyphen Admin UI, the steps are simplified:

1. Provision foundational infrastructure through the UI
2. Deploy services using standardized templates
3. Apply tenant-specific guardrails automatically

Onboarding became hours — in certain cases, minutes — not weeks.

Tradeoffs, Pitfalls, and Edge Cases

Platform engineering slows you down initially.

You are investing in abstractions before immediate product features. You are standardizing deployment patterns, codifying infrastructure, and building self-service workflows. These efforts don’t directly ship customer value, but they define how all future work gets done.

In the short term, this feels like friction. Teams spend time building reusable patterns instead of one-off solutions.

Without this investment, early progress appears faster, but it leads to compounding chaos:

• Inconsistent deployment and infrastructure patterns
• Environment drift and operational fragility
• Security and compliance gaps
• Increased reliance on SRE for routine tasks

What feels like speed early on becomes a bottleneck later.

Platform engineering trades short-term velocity for long-term scalability and reliability.

Opinionated Templates Reduce Freedom

There is a constant tension between shipping customer features and investing in platform capabilities.

In the short term, bypassing shared patterns feels faster. Teams can move quickly by making local decisions and tailoring solutions to immediate needs.

Golden paths introduce constraints. They standardize how services are built and deployed, which can feel restrictive especially under delivery pressure.

Opinionated templates address this by encoding best practices into defaults, reducing decision-making overhead while maintaining consistency.

Standardization is not bureaucracy.
It is operational leverage.

Over-Engineering the Platform

Platform teams often fall into the trap of building things that are technically impressive but operationally unnecessary.

This often shows up as:

• Creating complex abstraction layers that few teams fully understand
• Designing highly generic frameworks before real use cases emerge
• Over-automating edge cases that are rarely encountered

These efforts can feel like progress, but they introduce additional complexity, increase maintenance overhead, and slow down adoption by engineering teams.

In many cases, the platform becomes harder to use than the problems it was meant to solve.

The goal must remain clear: reduce friction and increase velocity.

Treating the Platform as a Gatekeeper

If platform engineering principles become a bottleneck, you’ve failed.

Optimize for:

• Self-service
• Templates
• Automation

Platform engineering should enable velocity — not control it.

The real decision is not whether to invest in platform engineering. It’s whether you want complexity to grow accidentally, or intentionally shape it from day one.