Engineering grid flexibility at scale: why Voltus chose marimo

Will Lachance - Staff Software Engineer, Voltus

When the power grid is under stress, operators need a way to quickly reduce load or bring extra capacity online. Voltus does this by aggregating distributed energy resources (DERs) across North America — industrial HVAC systems, battery storage, qualified backup generators, and more — coordinating them to respond to dispatch signals as if they were a single power plant. With 8.5 GW under management, Voltus was named the #1 aggregator in Wood Mackenzie’s 2025 VPP Report.

As a staff software engineer at Voltus, I have been heavily focused on building out Voltus’s internal data platform and tooling since I started working here in early 2022. One of the things that attracts me to Voltus (aside from a compelling mission) is how deeply collaborative our culture is. People from Energy Markets, Dispatch Operations, Engineering, and other teams routinely work together on the same problems using the same technology. Although we are a company building a product to address our customers’ needs, tools that came out of scientific research like Jupyter and marimo have proven to be a great fit for how we work. We adopted marimo — the open source, reactive notebook for Python — because it brings standard software engineering principles to interactive computing, while still making it easy for almost anyone in the company to make and share interactive applications and workflows.

Cross-functional engineering as culture

Since its inception, the collaboration between our expert team with deep energy markets expertise and software engineering has been core to how Voltus operates. Our products seamlessly blend the distinct expertise of peers in Operations, Energy Markets, Compliance, and Software Engineering. One of our engineering operating values is “Curiosity and Humility”: we learn generously from our peers in other departments, and they in turn, learn from us.

To establish a common language across these disciplines, the Python programming language and the broader data science ecosystem became fixtures at Voltus in our early days. Software like Jupyter, pandas and dask became our foundational bridge, empowering market experts and engineers to collaboratively translate complex regulatory nuances directly into software.

From process-heavy auditing to tool-based determinism

While our early adoption of notebooks facilitated unprecedented collaboration, it also introduced scale-related challenges. Historically, Voltus maintained extensive, rigorous internal auditing protocols for our data science workflows to ensure our collaborative tools met the demanding standards of our industry.

In a practical sense, this meant working around Jupyter’s limitations. For example, to work around the lack of built-in version control, notebooks were often named things like telemetry-aggregation-jsmith-march-2025.ipynb. This might seem awkward, but it worked remarkably well and was much more scalable than the alternative of having engineers re-implement everything from scratch.

One hard lesson we learned over time was that producing compelling user-facing applications in Jupyter, although possible, was hard. We used tools like ipywidgets and appmode to create user interfaces, but using them effectively required both JavaScript knowledge and Python details, making application development in Jupyter more the domain of Engineers (and a small number of very sophisticated Energy Markets analysts). Tasks like making a chart render differently in response to user input involved using a global variable, which involves workarounds like using global due to callbacks and Jupyter’s scoping rules:

fig = go.FigureWidget()
 
def on_click(btn):
    global fig
    fig.data = []
    fig.add_scatter(...)
 
button.on_click(on_click)
display(button, fig)

Having to learn about an unintuitive concept like global is bad enough, this code also has a hidden footgun: if someone redefines fig in another cell, the widget will cease to work as designed. Even experienced software engineers would often struggle to produce a simple dashboard, let alone someone with a different background.

For years, I felt there had to be a better way. Before 2025, the traditional answer was to use a BI tool like Looker or Retool. However, based on my experience as a data engineer at Mozilla, I found these tools took years-worth of engineering time to roll out properly. And even after committing significant resources, they often failed to deliver the promised benefits over simpler tools like Jupyter. Moreover, products like these tend to increase the disconnect between Engineering (who usually build application code or lower level data pipelines) and other departments. The last thing I wanted to create was another silo.

I felt like there had to be a middle ground that preserved the flexibility of Jupyter while improving some of its known deficiencies. After trialing marimo in early 2025, I knew it had incredible promise: it solved virtually all the issues we had in Jupyter around reproducibility and scoping, while dramatically lowering the barrier to creating interactive applications.

The marimo advantage at Voltus

marimo brings standard software engineering principles to the flexibility of the Python notebook ecosystem:

• Deterministic execution: marimo’s reactive engine eliminates the “hidden state” of legacy notebooks. When variables change, the entire system updates predictably. This replaces manual verification with architectural guarantees, eliminating an entire class of execution errors by design. For example, when a site performance calculation is changed in a visualization, all dependent variables and calculations will automatically update along with it: just like a spreadsheet.
• Built-in support for creating web applications: marimo’s support for running notebooks as applications is built-in from the ground level. When run in this mode, the code is hidden and all the user sees is the output of any cells, along with any user interface or textual description that the developer cares to add. marimo also comes with a great number of useful controls and visualization tools right out of the box.
• Zero-overhead version control: While Voltus has always utilized Git for source control, marimo’s pure .py format removes the notorious friction of reviewing JSON-based notebooks. marimo has plugged seamlessly into our existing CI/CD pipelines, ensuring standard GitHub peer reviews and automated tests are as clean and readable as traditional backend engineering.

The lifecycle: From sketch to schedule

One thing we’ve found at Voltus is that our processes typically go through a distinct lifecycle from prototype to production. You want a tool that’s comprehensible to people at every step of the way. A simple “team X hands off requirements to engineering” rarely works well given the complexity of the domain we operate in. marimo provides a seamless, highly auditable lifecycle for our cross-functional tools without requiring code rewrites. A tool matures through three distinct phases within a single repository:

1. Transparent prototype: Analysts draft version-controlled, shareable models that are visible across the markets and Engineering teams from day one, using a custom sandboxed environment based on GitHub Codespaces.
2. Human-in-the-loop app: With marimo’s FastAPI integration, prototypes instantly become reactive, production-grade applications where human operators can verify complex outputs.
3. Verified automation: Fully vetted logic is scheduled to run autonomously, posting output summaries for periodic audit while retaining a clear evolutionary history. Notebooks can be seamlessly integrated with our Dagster-based workflow scheduling system.

Throughout this lifecycle, we can continue to use the same tool (marimo) which enables continued understanding and development by the same cross functional group. Adoption has been widespread across Voltus.

Solving customer problems: The interactive sandbox

This engineering rigor directly benefits our partners. Testing DER integrations for compliance is traditionally a manual, high-touch process fraught with regulatory risk. Using marimo, we embedded a reactive, self-service sandbox directly into our documentation. Today, partners can safely self-schedule complex test dispatches and verify expected behavior in real-time.

By leveraging marimo, we provide partners with a reactive sandbox where they can adjust parameters and instantly visualize dispatch timelines and operational impact, eliminating the back-and-forth typical of manual integration testing. Both partners and our Field Engineering team love this tool because it reduces the need to explain complicated concepts on live calls and increases confidence that they’ll perform when they go live.

(See the live tool here: https://api.voltus.co/docs/tutorials/test-your-dispatch-integration)

Conclusion

The energy industry doesn’t leave much room for error, and the tools we use have to reflect that. What surprised and delighted us about marimo was that it didn’t force a tradeoff — we got the reproducibility and auditability we needed for a regulated, high-stakes environment, while actually making our workflows more accessible and enjoyable to use.

marimo is the world’s best programming environment for working with data, and it’s all free and open source. Just pip install marimo or uv add marimo to get started.