Why headless for a content platform at this scale?

Headless architecture — in this case Next.js on the frontend, Nest.js on the backend — decouples content management from delivery, which is what lets the platform serve sub-100ms responses to millions of users while editors work in a separate, optimised admin interface. The trade-off is operational complexity (two systems to run, not one), and we don't recommend headless by default. For content-first platforms where read performance and editor velocity both matter, the trade-off is worth it.

How long does building a platform like this take?

The deployment cycle here was 20 weeks: 4 weeks of discovery and prototyping, 8 weeks of MVP engineering, 8 weeks of global scaling. That timeline reflects a defined scope — 24,000+ entries, 29+ locales, sub-100ms global latency. Projects with materially different scope or constraints land in different windows.

How does automated media processing affect SEO?

In two ways. First, asset quality directly affects user signals — bounce rate, dwell time, perceived authority — which Google has used as ranking inputs for years. High-fidelity, sticker-free 2K/4K assets read as authoritative. Second, optimised WebP delivery reduces page weight, which improves Core Web Vitals scores. The combination of both is what generated the organic traffic curve.

Can a wiki catalogue be cleanly integrated with an existing product ecosystem?

Yes, if it's designed for it from the start. The pattern that worked here was a separate domain — so the wiki could rank independently in search — combined with SSO and ecosystem integration on the user side. This let the platform operate as an autonomous traffic source while staying part of the core product experience for logged-in users.

How do you maintain data integrity across 24,000+ entries in a volatile market?

By treating no single data source as authoritative. The backend engine aggregates and normalises feeds across three stream types — pricing, volume, metadata — in real time, and surfaces anomalies rather than passing them through. When market data disagrees across sources, the platform has explicit logic for resolution rather than silently inheriting one feed's noise.

Can you share the client name?

The client name is withheld under NDA. Get in touch if you'd like to discuss the engagement in more detail under a mutual NDA — we can walk through the architecture and operational decisions at a level not appropriate for public material.

Healthcare Compliance Platform

Re-architecting a clinical SaaS for HIPAA and GDPR compliance while expanding product capabilities.

North America + Europe

100%

First-attempt pass on HIPAA + SOC 2 + EU GDPR DPIA

140+

Migrated to compliant patterns without service interruption

92%

Up from 31% baseline

5×

From bi-weekly manual releases to daily automated deployments

3D cloud icon surrounded by data charts and blocks on a light blue background.

#HealthTech

#Compliance

#HIPAA

#Kubernetes

#GDPR

#Cloud-Native

#Microservices

#AWS

#PostgreSQL

#DevSecOps

Context

A product company operating a clinical decision-support SaaS across North America and Europe needed to move from a fast-iterating MVP architecture to a production-grade platform that could satisfy HIPAA (US), GDPR (EU), and a forthcoming SOC 2 Type II audit. The platform serves clinical teams, integrates with EHR systems, and handles Protected Health Information (PHI) across hundreds of daily transactions.

The internal team was strong on product features but had no in-house expertise in healthcare-grade compliance. Previous attempts to engage a Big Four security consultancy had produced an extensive audit report and a fixed-price remediation quote — but no actual change in the team's ability to maintain compliance after the project ended. The client wanted both: pass the audits, and never need a vendor for compliance again.

This is where MetaProject was brought in.

The problem

When we started discovery, we found a pattern familiar to fast-growing healthtech products:

PHI flowed through 140+ endpoints without consistent classification or boundary enforcement

Access controls were enforced at the application layer but inconsistently at the database layer

Encryption-at-rest was in place, but encryption-in-transit was inconsistent for internal service-to-service calls

Audit logs existed in pockets — some services, some operations, no unified event model

Deployment was bi-weekly, manual, with no security scanning gates

The team had read the HIPAA Security Rule but had no operational model for translating it into engineering practice

A surface-level remediation could pass the audit on paper. A capability transfer required something deeper: rebuilding the way the team thought about, designed, and shipped PHI-handling code.

What we built together

MetaProject embedded a small senior team (four engineers + one engineering coach) alongside the client's existing squads. Over eleven months, we focused on five capability layers, each transferred to the internal team before we moved on.

Architecture standards

We codified the eight diverging service patterns into one. We documented APIs, error handling, eventing, persistence, and observability conventions. New service templates were generated from the standard, so squads couldn't easily diverge again. Every standard was tied to an Architecture Decision Record (ADR) explaining the trade-off.

Internal Developer Platform (IDP)

We bootstrapped a platform team from two existing senior engineers (rather than waiting on external hires). We built a self-service deployment flow on Kubernetes with GitOps, an internal service catalog, and a paved road for new services. Onboarding time for a new engineer dropped from six months to six weeks.

Product delivery operating model

We re-shaped the squad structure around stable product domains rather than projects. We introduced a flow-of-work model with explicit WIP limits, prioritization forums tied to business outcomes, and lightweight architecture governance through a federated review group. The endless architecture review meetings were replaced by asynchronous ADR reviews with named decision owners.

Centre of Excellence transition

We helped design and stand up the company's internal Engineering CoE — a small group (five senior engineers, rotating) that owned architectural standards, platform roadmap, and engineering practices. We did not staff the CoE. We trained it.

Knowledge transfer systems

Every artifact we produced lived in the client's own systems from day one. We co-wrote the engineering handbook. We ran weekly internal tech talks that grew into a regular practice the team continued after we left. We built a Skills Matrix mapping each capability to who in the team owned it.

Timeline

The engagement followed our three-phase model:

Phase 1

Co-execution (months 1–4)

MetaProject senior engineers led the architecture rework, wrote the first ADRs, and built the CI/CD security pipeline. Client engineers worked alongside, pairing on every significant change.

Phase 2

Transition (months 5–7)

Client engineers led new feature work using the patterns we had established. MetaProject moved into mentor and reviewer roles: code review, architecture forum chair, runbook drills.

Phase 3

Self-sufficiency (months 8–9)

The internal CoE structure was in place. MetaProject stepped back to a monthly counsel role. The client's first independent HIPAA audit and SOC 2 Type II audit were passed without our involvement in the audit response.

Outcomes

By the end of nine months, the client had:

Passed all three target audits

(HIPAA Security Rule, SOC 2 Type II, EU GDPR DPIA) on first attempt

Reduced deployment cycle time

in the 18 months following launch

Zero data-related security incidents

in the 18 months following launch

Built an internal compliance capability

four engineers trained as compliance champions, owning all compliance reviews

Reduced reliance on external consultants

for compliance from "every audit" to "ad-hoc strategic counsel"

Increased product velocity

the team could now ship PHI-handling features faster than before the rework, because compliance was no longer a separate gating step

Why this engagement worked

Three things made the difference:

No junior bench

Every MetaProject engineer on the project was a senior with prior healthtech compliance experience. We didn't learn HIPAA on the client's time.

Documentation-first

Every architectural choice, every standard, every runbook lived in the client's own systems from day one. There was nothing in a vendor's private notes that mattered to the platform's future.

Exit by design

The engagement was scoped, from the kickoff, with a defined transition out. The client's leadership knew, from week one, what self-sufficiency would look like and what milestones marked the path to it.

Stack snapshot

Cloud

AWS (multi-region, with EU data residency for European users)

Compute

EKS (managed Kubernetes), Lambda for event-driven workloads

Data

PostgreSQL (RDS, with row-level security), DynamoDB for high-velocity event streams

Data

PostgreSQL (RDS, with row-level security), DynamoDB for high-velocity event streams

Compliance tooling

OPA (policy-as-code), Trivy, Snyk, Vault, AWS KMS, AWS GuardDuty

CI/CD

GitHub Actions with custom security workflows, ArgoCD for GitOps deployment

Authentication

Auth0 with SAML SSO for clinical users, MFA enforced, session policies aligned with HIPAA

Need a similar transformation?

If you operate a healthcare product and you're facing HIPAA, GDPR, or SOC 2 — and you want to leave the engagement with a team that can maintain compliance without us — that is what we are built for.

Start a Capability Blueprint Workshop

Client name withheld under NDA. Outcomes verified through joint post-engagement review.