Platform Engineering for NEOM and Giga-Projects: Internal Developer Platforms at Massive Scale

Saudi Arabia’s giga-projects represent the largest simultaneous infrastructure build in modern history. NEOM, Red Sea Global, ROSHN, Qiddiya, Diriyah Gate, and The Line are not just construction programmes - they are technology programmes. Every smart building, autonomous transport system, energy grid, and guest experience platform requires software. And the engineering teams building that software are scaling faster than any organisation in the region has attempted before.

The question is not whether these programmes need platform engineering. The question is whether they can afford to delay it.

The Giga-Project Engineering Challenge

A typical Vision 2030 giga-project starts with a founding engineering team of 15-30 engineers. These early engineers build the initial systems, establish the CI/CD pipelines, configure the cloud infrastructure, and create the deployment processes. Everything works because everyone knows everyone. Knowledge transfer happens in meetings and Slack channels.

Then hiring accelerates. The team grows to 80 engineers across five squads. Then 200 across twelve squads. Then 400+ with new squads forming monthly. At this point, three critical failures emerge simultaneously.

First, the provisioning bottleneck. Every new squad needs infrastructure - a Kubernetes namespace, a CI/CD pipeline, a staging environment, database instances, service mesh configuration, and monitoring dashboards. The platform team that built the original infrastructure is now buried under tickets from twelve squads, each waiting days or weeks for basic provisioning.

Second, the consistency problem. Each squad configures things slightly differently. One squad uses Helm charts while another uses raw manifests. Logging formats diverge. Monitoring coverage varies. When an incident occurs at 2am, the on-call engineer faces a patchwork of configurations they have never seen before.

Third, the compliance gap. NCA Essential Cybersecurity Controls require uniform security configurations - encryption, audit logging, network segmentation, access controls. At 30 engineers, a security review can catch deviations manually. At 400 engineers deploying multiple times per day, manual compliance checking is impossible.

What an Internal Developer Platform Looks Like at Giga-Project Scale

An internal developer platform (IDP) is not a single tool. It is an integrated system that gives engineering squads self-service access to everything they need to build, deploy, and operate services - without filing tickets to a central platform team.

For a Saudi giga-project, the IDP typically includes five layers.

Layer 1: Infrastructure Orchestration

At the base, Terraform or Pulumi modules define the infrastructure building blocks - Kubernetes clusters, database instances, message queues, storage buckets, networking configurations. These modules encode NCA compliance by default: encryption at rest using AWS KMS with keys stored in the Riyadh region, CloudTrail logging enabled, VPC segmentation enforced, and IAM policies following least-privilege principles.

Engineers never write raw Terraform. They consume modules through a self-service catalogue that provisions pre-approved, compliant infrastructure in minutes rather than days.

Layer 2: Golden Paths

Golden paths are opinionated templates that cover 80% of use cases. A developer creating a new microservice runs a single command and receives a fully configured repository with CI/CD pipeline, Dockerfile, Kubernetes manifests, monitoring configuration, logging integration, and a staging environment - all wired together and all compliant with organisational standards.

For a NEOM-scale programme, golden paths might include:

• Standard microservice - Go or Java service with REST API, PostgreSQL database, Prometheus metrics, and Grafana dashboard
• Event-driven service - service consuming from Kafka or Amazon EventBridge with dead-letter queue handling
• IoT data pipeline - ingestion service for smart building or energy management data with time-series storage
• ML model serving - containerised model with GPU support, A/B testing, and model versioning

Each golden path enforces PDPL data residency by defaulting all resources to the AWS me-central-1 (Riyadh) region, with cross-region replication explicitly disabled for personal data workloads.

Layer 3: Developer Portal

Backstage serves as the single pane of glass for the entire engineering organisation. It provides a service catalogue showing every running service, its ownership, documentation, API specifications, and health status. It provides the self-service interface for golden paths. It shows the deployment history, incident history, and SLO compliance for every service.

At 400+ engineers, Backstage becomes the organisational memory. When a new engineer joins a squad, they can find every service their squad owns, read the documentation, understand the dependencies, and trace the deployment pipeline - without asking anyone.

Layer 4: CI/CD Backbone

The platform provides a standardised CI/CD backbone - typically GitHub Actions or GitLab CI with shared pipeline templates. Squads do not build their own pipelines from scratch. They inherit a pipeline from their golden path that includes build, test, security scan (Trivy, Snyk), NCA compliance check (Open Policy Agent), and progressive deployment (canary or blue-green).

The platform team maintains the pipeline templates. When a new security scanning requirement emerges - for example, a new NCA control - the template is updated once and all services inherit the change on their next deployment.

Layer 5: Observability

The platform provides a unified observability stack - typically Prometheus for metrics, Grafana for dashboards, OpenTelemetry for distributed tracing, and a centralised logging solution (Loki or Elasticsearch). Every golden path service ships with pre-configured instrumentation, default dashboards, and alerting rules.

This matters enormously at giga-project scale. When a smart building management system in NEOM reports an anomaly, the on-call engineer needs to trace the request across ten microservices in seconds - not spend 30 minutes figuring out which services have logging enabled and which do not.

NCA Compliance at Scale: Policy-as-Code

NCA Essential Cybersecurity Controls are not optional for government-adjacent technology programmes. For giga-projects operating under Saudi government oversight, NCA compliance must be continuous, automated, and auditable.

Policy-as-code using Open Policy Agent (OPA) or Kyverno enforces NCA controls at multiple levels:

• Infrastructure level - Terraform plans are validated against NCA policies before apply. A module that creates an unencrypted S3 bucket is rejected automatically.
• Deployment level - Kubernetes admission controllers reject pods that run as root, lack resource limits, or reference container images from untrusted registries.
• Runtime level - continuous compliance scanning detects configuration drift and triggers alerts or automatic remediation.

The platform team writes the policies once. Every squad inherits them. NCA compliance becomes a property of the platform rather than a responsibility of individual engineers.

SDAIA and Data Governance Integration

Saudi Arabia’s SDAIA (Saudi Data and AI Authority) has established data governance frameworks that apply to giga-project technology programmes. The internal developer platform must integrate data classification and governance into the golden paths.

This means infrastructure provisioning templates must support data classification tagging - labelling storage resources as containing personal data, sensitive government data, or public data. Each classification triggers different encryption, access control, and audit logging configurations. The platform enforces these classifications automatically, ensuring that a developer who creates a database for personal data gets PDPL-compliant encryption and access controls without manual configuration.

Measuring Platform Success

The metrics that matter for a giga-project IDP are concrete and measurable:

• Time to first deployment - how long from a new engineer joining to their first production deployment. Target: under one day.
• Service provisioning time - how long to scaffold a new service with CI/CD, monitoring, and staging. Target: under 30 minutes.
• Ticket volume to platform team - the number of provisioning and configuration requests. This should decrease as self-service adoption grows.
• NCA compliance rate - percentage of services passing automated compliance checks. Target: 100% for new services.
• DORA metrics - deployment frequency, lead time for changes, change failure rate, and mean time to recovery. These should improve as the platform matures.

For NEOM-scale programmes, the business case is straightforward. If the platform reduces time-to-production by 60% across 400 engineers, the productivity gain is equivalent to hiring 240 additional engineers - without the Iqama timelines, Nitaqat complexity, or SAR salary costs.

The 16-Week Engagement for Giga-Projects

We recommend a phased approach for Vision 2030 giga-projects:

Weeks 1-3: Discovery and architecture. Map current engineering workflows, identify the top five provisioning bottlenecks, assess NCA and PDPL requirements specific to the programme, and design the platform architecture.

Weeks 4-8: Golden path MVP. Build the first two golden paths covering the most common service types. Deploy the infrastructure orchestration layer with NCA-compliant modules. Establish the CI/CD backbone with shared pipeline templates.

Weeks 9-13: Developer portal and observability. Deploy Backstage with service catalogue integration. Stand up the observability stack with pre-configured dashboards. Implement policy-as-code for automated NCA compliance.

Weeks 14-16: Adoption and handover. Migrate the first five squads to the platform. Train the internal platform team. Document the platform architecture and operational runbooks.

Getting Started

If you are building technology for a Saudi giga-project and your engineering team is scaling faster than your DevOps processes can support, platform engineering is the investment that determines whether you ship on schedule or accumulate months of technical debt.

devopssaudi.com specialises in internal developer platforms for Saudi Arabia’s largest technology programmes. Book a free 30-minute consultation - we will assess your current platform maturity and outline what an IDP engagement would look like for your programme.