From 3-Day Setup to 1-Day Productivity: How EnBW Powers Energy Trading Development with Coder

Company overview

EnBW Energie Baden-Württemberg AG is one of Germany’s largest energy companies, with operations spanning electricity generation, energy trading, grid infrastructure, and retail services. Within EnBW’s energy trading division, a dedicated platform engineering team serves as the internal enablement engine for data scientists and software developers building the tools and infrastructure that power daily trading operations.

Stephan Kunz is the Product Owner for the Trading Workbench, providing a centralized development toolbox that supports everything from cloud infrastructure provisioning to day-to-day software development within the energy trading area. Sebastian Petzold, Martin Meszaros and Lars Mezler are Platform Engineers and Solutions Architects who drove the full evaluation, implementation, and ongoing development of EnBW’s cloud development environment strategy. Sebastian Petzold and Martin Meszaros are external contractors from just.nerds IT consulting, while Lars Mezler represents Lars Mezler Software Consulting. Together, they manage a platform that serves roughly 150 developers and data scientists working across a broad range of analytical and engineering workloads.

The challenge

Data science is resource-intensive by nature. Model training, exploratory analysis, and complex pipeline development demand flexible compute, diverse libraries, and runtime environments that evolve constantly. For EnBW’s developers and data scientists, the existing setup created friction at every stage of their work. Corporate IT policy locked down local development machines, preventing developers from installing the tools they needed without administrator privileges. The predictable result was a fragmented landscape where every developer maintained their own environment, their own toolchains, and their own institutional knowledge about what worked on their specific machine. No two setups looked alike, and the platform team had no reliable way to enforce consistency.

For the team responsible for keeping development infrastructure running, this fragmentation created serious operational problems. When something broke, diagnosing the issue meant first reverse-engineering how that particular developer had configured their machine. Support was slow, opaque, and expensive in engineering hours.

New hire onboarding reflected the same dysfunction. Getting a developer productive required navigating permission requests, manually installing dependencies, configuring runtimes, and working through the inevitable compatibility issues. That process typically took three to four days before a new joiner could write a single line of working code. For a team that depended on velocity, the cost was significant.

The team also had no clean path to internal data services. Connecting to databases and services running in AWS required complex jump-host configurations that were difficult to maintain and behaved inconsistently across users. And because all development happened locally, sensitive data could end up on developer laptops, introducing real security exposure.

Before Coder, everyone was doing whatever they liked, and everything was mixed up. The setups looked different for every person. When something didn’t work, you had to go really deep into the situation just to understand what was going on.

Martin Meszaros, Platform Engineer, EnBW (contractor)

The solution

The EnBW platform team evaluated several cloud development environment options before selecting Coder. What distinguished Coder was its flexibility. Rather than enforcing a rigid, opinionated workflow, Coder gave the team the building blocks to design an architecture that fit how EnBW actually operates.

The implementation reflects that flexibility in practice. EnBW built a self-service model in which individual project teams can provision their own Coder integration directly within their own AWS accounts. Each team runs workspaces inside their own cloud environment, with the permissions and data access they need built in from the start. The platform team maintains and updates workspace templates centrally, but the compute lives close to where the work happens.

Developers now access pre-configured workspaces through a simple portal. Updates, dependency management, and environment standardization all happen at the platform level. When a developer starts their day, they open the Coder portal, start their workspace, and get to work.

Key capabilities that shaped the deployment:

• Workspace templates that standardize environments across teams while allowing project-specific customization
• Direct connectivity to internal databases and services running in AWS, without jump-host complexity
• Automatic idle shutdown to prevent unnecessary compute costs between active sessions
• Elastic resource scaling that lets users dial up compute for model training and scale back when the job is done
• Support for external contributors using personal devices, with all development occurring securely inside the cloud workspace

The results

Since deploying Coder, EnBW has standardized development infrastructure across its energy trading engineering teams, reducing operational overhead, improving security posture, and transforming the developer experience from onboarding through daily work.

Coder brings order into your daily development situation. It makes our lives easier when debugging issues, and it makes the lives of actual users easier because they don’t have to deal with weird permissions or getting stuff installed and maintained.

Martin Meszaros, Platform Engineer, EnBW (contractor)

Onboarding transformed

The three-to-four day onboarding process is gone. New developers now log into the Coder portal, start a pre-configured workspace, and are contributing code on day one. Every library, every internal tool, and every permission is ready from the moment they log in. The pltform team prepares all of that in advance, so a new joiner’s first interaction with their development environment is not a setup process.

Infrastructure that scales with the work

With compute-intensive workloads moved to the cloud, EnBW no longer needs to provision high-end laptops for every data scientist or developer. Standard corporate devices are sufficient because the heavy lifting happens in AWS. Elastic scaling means developers can request the resources they actually need for a training run or large analysis job, then release them when the work is done. Automatic idle shutdown keeps cloud spend in check during inactive periods.

Security and supportability

Data no longer leaves the cloud development environment. Code, model artifacts, and sensitive data stay in AWS, reducing the risk of local exposure that came with the previous laptop-centric approach. Direct connections to internal databases and services, which previously required complex jump-host configurations, now work natively from within the workspace.

For the operations team, supportability has improved significantly. Standardized, reproducible environments mean incidents can be investigated without first reconstructing a developer’s unique local setup. The platform team can observe, diagnose, and resolve issues faster, with full visibility into the environment state.

External collaboration without hardware overhead

External contributors represent a meaningful additional benefit. When contractors or third-party collaborators need to participate in development work, EnBW can grant secure access to a cloud workspace without issuing corporate hardware. The security boundary holds regardless of what device the contributor is using, which makes the process both faster and less costly to manage.

Looking ahead

Coder has been in active production at EnBW for more than two years, supporting approximately 150 developers and data scientists. With that foundation in place, the team is now exploring the next wave of capabilities. AI-assisted development is gaining traction internally, and the platform team is actively investigating how Coder’s AI Governance features can bring control and observability to those workflows, including dictating which models developers can access and capturing usage data across the environment.

The decentralized, self-service architecture that EnBW has built will require additional work to fully support agentic development workflows, but the interest and momentum are there. As the energy sector continues to move toward data-intensive operations and automated analysis, having a stable, governed development platform will become even more important to the team’s mission.

Conclusion

For EnBW’s platform engineering team, Coder delivered more than faster onboarding. It delivered a coherent, controllable development infrastructure where fragmentation and inconsistency once made every support interaction harder than it needed to be. Developers spend less time configuring environments and more time building the tools that keep energy trading operations running.

By moving development into governed, cloud-based workspaces, EnBW eliminated the hidden costs of decentralized local environments, reduced security exposure, and gave the platform team the visibility they need to support a growing and diverse developer population. The result is a development platform that scales with the organization rather than against it.