Battery Modeling Software Development for Stanford's STEER Initiative

The Client

STEER is a Stanford University think-and-do tank for the clean energy transition. Its work bridges the gap between research and implementation—answering the questions energy stakeholders face most: what to build, where to innovate, and how to invest.

The economics of battery technology are determined at the cell level—in material choices, electrode configurations, and design tradeoffs. OpenCell is the tool STEER built to navigate those decisions. Engineers use it to model a battery cell from the ground up: selecting active materials, defining electrode formulations, configuring assemblies, and filling with electrolyte—with every parameter change feeding directly into real-time techno-economic calculations of energy performance and unit cost.

Powerful as a research instrument, OpenCell had outgrown the infrastructure it ran on. Transforming it from a single-user local tool into a multi-user SaaS platform where researchers and engineers could save, share, and collaborate on designs—is what brought STEER to Binary Studio.

Binary did really well.

They delivered on time. They worked overtime to ensure we delivered even ahead of time, which I found very impressive. They were clear on the timelines from the onset and kept pace. During the development, we had ideas for further improvements beyond the original plan, and they delivered on those, too.

Battery Modeling Software Development for Stanford's STEER Initiative-2

Nicholas Siemons

Software Lead

Battery Modeling Software Development for Stanford's STEER Initiative-3 USA

Objectives

When our team engaged with STEER, OpenCell was a sophisticated tool not structured for collaborative or commercial use. It ran off a local SQLite database bundled inside a Python package, had no authentication system, and relied on a fully manual PyPI-based deployment process with no infrastructure automation.

The objectives were clear:

01

Move from a local tool to a cloud-hosted multi-user platform

OpenCell needed a complete backend migration—from local SQLite to AWS—with persistent storage, concurrent user support, and clear separation between a public reference library and private user collections. The commercial goal was equally direct: enable a public beta launch.
02

Build authentication system, role-based permissions, and a curation workflow

The platform had no login system at all. The engagement required user accounts with three roles—guest, registered user, and administrator—each with appropriate data boundaries. It also required a submission workflow: a way for users to propose designs for the public library without exposing their private collections to administrators.
03

Introduce solid and scalable infrastructure within startup constraints

STEER had zero infrastructure automation—no IaC, fully manual PyPI-based deployment. The objective was a reproducible, version-controlled, and auditable cloud infrastructure. Equally important was doing it cost-efficiently: the right architecture could reduce infrastructure costs dramatically compared to conventional always-on alternatives, and the existing PyPI deployment workflow had to be preserved exactly as the client had it.

Greentech Software Development for Research and Energy Teams

Count on us to transform specialized engineering tools into scalable cloud solutions while preserving the scientific accuracy your work depends on.

Learn more

Solution and Outcome

We approached the project with a two-developer team, working across architecture, infrastructure, backend, and application integration.
The engagement opened with a structured discovery process—two rounds of stakeholder Q&A that surfaced ambiguities the specs had left open: which authentication system to use, how to handle DNS and deployment strategy, and how to secure public endpoints without adding friction for legitimate users. Every question the client had flagged as uncertain became a documented architectural decision with a clear rationale.
This groundwork shaped every technical choice that followed.

Python

Dash

AWS Lambda

AWS API Gateway

DynamoDB

AWS S3

AWS Cognito

CloudFront

AWS WAF

Terraform

Redis

Stage 1
Cloud Infrastructure and Backend API
The first stage established the architecture everything else would depend on. We designed and provisioned a complete AWS serverless stack — API Gateway, Lambda, DynamoDB, S3, Cognito, CloudFront, and WAF — deploying 44 cloud resources using Terraform.
The platform's constraints shaped two key decisions:
- Battery cell files reach 15 MB each — too large for standard database storage or API transfer — so rather than routing them through the backend, the system issues short-lived download links and lets users retrieve files directly from cloud storage.
- For authentication, we recommended AWS Cognito over the self-hosted alternative the client had explored, eliminating a separate server to manage and delivering role-based access control out of the box.
With the infrastructure in place, all 64 existing records were migrated from the local database to the cloud and verified for integrity, followed by a REST API with 8 permission-enforced endpoints covering every material and cell operation. Users gained full account management—registration, login, logout, password recovery, and 30-day session persistence.
The shift to a serverless architecture reduced projected infrastructure costs by 85–90%—from an estimated $150–250/month for always-on EC2, RDS, and Keycloak to $10–30/month under a scale-to-zero model.
Before the stage closed, an automated test suite of 20 scenarios ran against the live environment validating authentication, data isolation, and admin controls—all passing.
Stage 2
Application Integration and Data Migration
With the backend live, the second stage turned to connecting the existing application to it—without disrupting the domain engine that powers OpenCell's battery calculations. The challenge was significant: approximately 200 data-loading call sites were spread across five Python packages with cross-repository version dependencies already badly out of sync—the deployed application was pinning a version of one package that the repository had superseded by a full major version. Any careless change to the data access layer risked not just application errors but silently corrupted physics calculations—invalidating the battery capacity and energy models that engineers depend on.
The solution was a DataManager adapter—a drop-in replacement that implemented the same interface as the original local database connection, but routed all calls to the cloud API instead. One module was swapped, and all 200 call sites continued working without a single modification. The battery material library and all existing cell designs migrated cleanly—verified by an expanded integration test suite of 28 assertions, all passing against the live environment.
Beyond the migration, Stage 2 delivered the features that made the platform usable as a shared tool. Researchers can browse designs by role, save and fork work from the design screen, and migrate individual records on demand. A dual-mode system lets the development team work locally without cloud access—keeping the existing workflow intact. And because a single cell design can represent weeks of engineering work, permanent deletion was replaced with soft delete.
Stage 3
Security and Documentation
The final phase added a design submission workflow that resolved an important privacy consideration: rather than allowing administrators to browse users' private collections directly, users explicitly submit designs for admin review, and administrators work only from a dedicated submissions queue. This preserved user privacy while giving STEER the content curation control needed to maintain a high-quality public reference library.
During this stage we also caught and resolved a set of issues that had only surfaced once the application was running in its live environment. The production setup caused authentication redirects, session handling, and page navigation to behave differently than they had in local testing. These were diagnosed and resolved before handover.
The engagement concluded with a full documentation package: 22 user stories across eight feature areas, 15 technical specification documents, and maintenance guides covering everything STEER needed to operate and extend the platform independently.

Battery Modeling Software Development for Stanford's STEER Initiative-16

Battery Modeling Software Development for Stanford's STEER Initiative-17

From Scientific Instrument to SaaS Platform

What made this project distinctive was not the scale of the migration—it was the domain it had to respect. OpenCell is a scientific instrument where every architectural decision carries a real risk: corrupted data deserialization could invalidate battery capacity calculations; a careless change to the data access layer could render electrode formulation models unreadable.
Our role was to make OpenCell collaborative and cloud-native without compromising the scientific rigor that makes it credible. That required genuine immersion in battery engineering—deep enough to make architectural decisions the computation engine could trust.
STEER can now offer OpenCell as a cloud-native multi-user platform technically ready for public beta. The tool that models battery cells at the physics level is now itself built to the standards of modern cloud software. For a Stanford initiative working to accelerate the energy transition, that means the work of designing better batteries—grounded in real-world data, evaluated against real economics—can finally happen across teams and institutions, not just on a single machine.

About Binary Studio

Binary Studio is a boutique software development company, regularly praised for its unique blend of engineering excellence and product ownership that enables its clients to build robust and scalable software products.
With our development team made up of top 0.5% international tech talent, we build web and mobile platforms using Node.js, .NET, React Native, Flutter, and integrating AI and ML. We also offer full-cycle QA and project management services to ensure the efficient delivery.
Our clients see us as a trusted partner dedicated to turning visions into great products. This is proven by 200+ delivered projects, more than two decades of business excellence, and stellar customer reviews.

Contents