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.

Product Company Capability Expansion

Doubling the feature delivery capacity of a B2B SaaS engineering team without doubling headcount.

Europe + North America

2.1×

Story points per quarter, same team size.

×4

From weekly to multiple daily deploys.

−62%

From idea to production, average.

−45%

Annualized external consulting and contractor spend.

+28pp

18 months after transition completed.

11 mo

Co-execution to fully independent CoE

3D digital network with colorful cubes, pie chart, and database icons connected on a purple background.

#SaaS

#B2B

#Microservices

#Platform Engineering

#CoE

#Cloud-Native

#AWS

#Kubernetes

#Knowledge Transfer

Context

A growing B2B SaaS company — operating across Europe and North America, serving mid-market and enterprise clients — had hit a familiar wall. Annual revenue was growing 40% year-over-year. Engineering headcount was growing too, but feature delivery wasn't keeping up. Every new hire took six months to become productive. Every architectural decision required either a long debate or a vendor recommendation. The CTO faced an uncomfortable choice: keep hiring at a rate that compressed margins, or admit that the platform could not scale with the product roadmap.

The board had previously approved bringing in a Tier-1 consultancy. The result was a 90-page strategic recommendation, no operational change, and a follow-on engagement quote that exceeded the engineering budget for the year. The CTO wanted something different: a partner that would build the company's own capability to deliver, rather than become a permanent line item.

This is the engagement we describe here.

The problem

Discovery surfaced a set of compounding constraints:

Architecture drift

Eight squads, each making independently reasonable decisions, had produced eight slightly different service patterns. Onboarding a new engineer meant learning eight conventions.

No platform team

Every squad maintained its own deployment scripts, observability config, and CI/CD pipelines. Tooling work was duplicated across squads.

Long lead time on cross-cutting changes

A change touching multiple services took three weeks to coordinate. Architecture review meetings ran weekly but produced few binding decisions.

Knowledge concentration

Three senior engineers held most of the operational knowledge. When one of them was on holiday, certain releases simply did not happen.

Hiring slowdown

The company had been trying to hire two senior platform engineers for nine months without success. The talent market was tight, and the role description had no clear scope of authority.

This wasn't a technology problem. It was a capability problem dressed up as one.

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

This engagement followed a longer-than-typical version of our three-phase model, because the client wanted us to also help with the platform team build-out:

Phase 1

Co-execution (months 1–5)

MetaProject led the architecture standards rollout, built the first version of the IDP, and chaired the architecture forum. Client engineers paired on every change. By month 5, two client engineers had become co-leads on the platform.

Phase 2

Transition (months 6–9)

Client engineers led platform work, ran the architecture forum, and drove standards evolution. MetaProject moved into mentor and reviewer roles. The CoE was formed. We co-designed the operating model with the client's VP Engineering.

Phase 3

Self-sufficiency (months 10–11)

Internal CoE owned all standards, platform, and architectural decision-making. MetaProject stepped back to monthly check-ins and ad-hoc strategic counsel.

Outcomes

Eleven months after engagement start:

2.1×

2.1× feature delivery capacity

at the same team size, measured in story points and confirmed in product roadmap velocity

4×

4× deployment frequency

from weekly to multiple daily deploys, with no increase in change-failure rate

95.47%

62% lead-time reduction

from idea to production 

45%↑

45% reduction in vendor dependency cost

annualized spend on external consulting and contracting

4 mo

Successful senior hires

the platform engineering roles that had been open for nine months were filled within four months of the new operating model, because the role scope was finally clear

CoE

Internal CoE running independently

five engineers rotating, with the company's own architectural roadmap

Why this engagement worked

We didn't replace the team. We made the team senior

Every change we made was paired with a knowledge transfer step. There was no "MetaProject did this" — there was always a named internal owner.

The CoE was built from inside

We could have parachuted a CoE team in. We didn't. The CoE was assembled from the client's own senior engineers, which made it credible internally and sustainable after we left.

Documentation-first

Every standard, ADR, runbook, and playbook lived in the client's own repos and wiki. When we exited, nothing important left with us.

Exit was a design constraint from day one

The transition timeline was set at kickoff. Every milestone was framed against "what's the team doing without us."

Why this engagement worked

We didn't replace the team. We made the team senior

Every change we made was paired with a knowledge transfer step. There was no "MetaProject did this" — there was always a named internal owner.

The CoE was built from inside

We could have parachuted a CoE team in. We didn't. The CoE was assembled from the client's own senior engineers, which made it credible internally and sustainable after we left.

Documentation-first

Every standard, ADR, runbook, and playbook lived in the client's own repos and wiki. When we exited, nothing important left with us.

Exit was a design constraint from day one

The transition timeline was set at kickoff. Every milestone was framed against "what's the team doing without us."

Stack snapshot

Cloud

AWS (multi-region, multi-account with org-level guardrails)

Compute

EKS, Lambda, Fargate

Data

PostgreSQL (RDS, Aurora), DynamoDB, Kafka (MSK) for eventing

Platform

ArgoCD, Backstage as service catalog, Terraform / Crossplane for IaC, OpenTelemetry across stack

CI/CD

GitHub Actions with shared workflows, SAST/SCA gates, SBOM generation

Observability

Grafana, Prometheus, Loki, OpenTelemetry traces; SLO/SLI dashboards per service

Engineering practices

ADRs in the main repo, monthly architecture forums, federated reviews

Want to expand your team's capabilities without expanding your team?

If your engineering organisation is growing but delivery isn't keeping up — and you suspect the answer is a stronger internal operating model, not more he

Start a Capability Blueprint Workshop

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

See more cases

Welcome Renovation

Engineering a productized renovation experience for the California luxury market — three apps, one source of truth.

#PropTech

#ConstructionTech

#Mobile

#iOS

#Android

#Stripe

#AWS

Skin.Club CS2 skins guide webpage displaying various weapon skins and knife designs including Doppler, Ultraviolet, Marble Fade, Freehand, and Damascus Steel.

This is some text inside of a div block.

Healthcare Compliance Platform

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

#HealthTech

#Compliance

#HIPAA

#Kubernetes

#GDPR

#Cloud-Native

#Microservices

#AWS

#PostgreSQL

DevSecOps

This is some text inside of a div block.

Singapore Payroll SaaS

Engineering a regulated payroll and HR platform — 20+ bank integrations, statutory tax automation, and the operational discipline a regulated SaaS demands from day one.

#PostgreSQL

#FinTech

#PayrollTech

#HRTech

#SaaS

#APAC

#.NET

#AWS