Global consulting firm

Client

At a large global consulting firm, accountants and business users build small services on a SaaS platform that needs powerful local machines. As the platform expanded across territories, the way developers got their environments was creating bottlenecks faster than the core team could absorb.

The local development setup is complicated. Building a service requires access to a database, several internal services, and an authorisation layer, all of which have to be available locally for testing. There are two main groups of builders:

1. Core developers and complex-service builders, who need the full development toolchain.
2. Simple-service builders working on standard handles (View, Transform, Action) with little customisation.

The rollout was already live in a handful of territories with more to follow, and each new country added support load the core team could not absorb at the same pace.

Challenges

Two things were making this harder than it needed to be:

• The local stack was deep: Node and npm, a couple of Python toolchains, several infrastructure components. Getting everyone on a consistent and working setup was a recurring tax.
• Corporate laptop policies are written for consultants, not for software developers. The technology team had MacBooks with more freedom to install tools, but that was not available in most countries.

The core team kept getting pulled into environment troubleshooting instead of working on the platform itself, and each new country pushed the support load up again.

On top of the environment work, the developers themselves needed:

• A real editor with syntax highlighting (VS Code or PyCharm)
• Working debugging
• The ability to run and verify their changes locally before pushing

What we did

We evaluated several options (a web-based “playground”, GitHub Codespaces, Microsoft’s cloud VS Code, self-hosted Azure VDI, a simplified local setup with a VS Code plugin) and shipped on Coder, hosted on Kubernetes inside the firm’s network:

• Standard environment templates per developer type, so a builder in any territory could get a working setup straight away.
• Each workspace had the developer’s editor of choice (VS Code or PyCharm), working debugging, and the dependencies the local stack required.
• The Kubernetes platform was sized to the workload rather than to whatever laptop someone got issued, with capacity that grew with the developer population.
• Operational patterns the core team could run: image rebuilds, workspace lifecycle, observability, and access through the firm’s existing identity systems.

The core team kept the original local setup for their own work and for the more complex builders who needed it.

Results

• Hundreds of developers ran their day-to-day work on the Coder platform.
• Onboarding a developer dropped from hours of setup plus weeks of troubleshooting down to minutes.
• Workspaces were disposable. When one broke, developers destroyed it and started a fresh one in a couple of minutes instead of debugging a local setup.
• Developers worked from any device with a browser, regardless of operating system or local hardware.
• The platform deployed consistently across territories, including the ones with stricter local laptop policies.
• The core team got large blocks of its time back from environment support, which freed them to work on the platform itself.
• Hardware and support costs dropped compared to the original local-machine model.