An internal developer platform that cut onboarding from weeks to days

Client

A legal services firm operating its own client-facing case management platform. Named details are withheld at the client's request.

Business challenge

Onboarding a new developer took weeks, most of it spent reproducing a working environment. Environments drifted apart, so defects appeared in production that could not be reproduced anywhere else. The engineering lead was spending a significant share of their week unblocking other people's setups.

Existing technical constraints

• Environments configured by hand and documented in a wiki page that had drifted
• No standard project scaffolding; every service solved logging and configuration differently
• Deployment steps held informally by two people
• Existing workloads on Google Cloud, which the firm intended to keep

Proposed architecture

This engagement was delivered on Google Cloud rather than AWS, because that was where the workloads already ran. The platform engineering practice is the same in either case; only the managed services underneath differ.

1. Service templates providing a scaffolded project with logging, configuration and health checks already wired
2. Environment definitions expressed as Infrastructure as Code, so an environment could be created and destroyed on request
3. A standard delivery pipeline inherited by every service from its template
4. Centralised secret management, removing credentials from local configuration files
5. A documented golden path, with deviation possible but deliberate

Implementation

The platform was built around one real service first and generalised only once it worked, which avoided designing for imagined requirements. Templates were adopted by migrating existing services one at a time. Documentation was produced as part of each template rather than as a closing task.

Security and governance

Secrets moved out of local files into managed secret storage with rotation. Access to environments was granted by role rather than to individuals. Pipelines gained dependency scanning, and the ability to deploy to production was separated from the ability to write code.

Outcome

• Developer onboarding reduced from weeks to days, with a working environment provisioned on request
• Consistent environments from local development through to production
• Deployment knowledge encoded in pipelines rather than held by two people
• Reduced interruption load on the engineering lead

Lessons and next phase

The templates mattered more than the tooling. Once a new service came with logging, configuration and a pipeline already in place, the golden path became the fastest route rather than the mandated one. The next phase covers service-level objectives and alert design.