Back Article Thumbnail

Increasing Battery Transparency at GM

Over the course of two summers interning at General Motors, I had the opportunity to contribute to a variety of projects across the company. Among them, one of the most exciting and impactful was my work on developing a battery passport—a tool designed to provide greater visibility into a battery’s information, lifecycle, and overall health.

Background

Before diving into what a battery passport is, it’s important to understand why this project was initiated. The concept originally emerged as a way for GM to get ahead of upcoming EU regulations on sustainable battery production. Under these policies, every battery would require a digital “passport” containing key details such as its carbon footprint, model information, and performance over time.

Beyond regulatory compliance, the project also aimed to expand the usefulness of the passport internally and externally. For internal teams, it offered a unified view of battery data, enabling better decision-making throughout the battery’s lifecycle. For consumers, it had the potential to become a valuable application for monitoring battery health and sustainability credentials—something third-party companies couldn’t easily provide, especially given the legal challenges around data ownership. In this context, building an in-house solution made the most sense, aligning both with compliance needs and long-term strategic value.

Planning Phase

Like most large-scale initiatives, a significant portion of time was devoted to planning the application and aligning with stakeholders. While this phase was less exciting than building the solution—it involved a lot of research, documentation, and diagramming—it was essential. Careful planning ensured that developers, stakeholders, and end-users shared the same vision, while also surfacing key business questions and design decisions early on.

During the first week, our team held design sessions to map user flows, identify stakeholders, and establish a high-level sprint plan. We also researched the regulatory requirements for the battery passport and brainstormed additional quality-of-life features that could make the tool more useful. This process culminated in a basic system diagram, built around a client–server architecture, which served as the foundation for the development work ahead.

Designing

A significant part of this project revolved around creating a clean, usable design. Usually for internal tools, my design skills are more than enough for creating an application that is both appealing and functional. However, this project was unique because it not only served internal GM teams (focus on functional queries), but also external customers (focus on user navigation). As such, to ensure the interface was professional and accessible, I collaborated closely with experienced designers throughout the process.

Using Figma, an industry standard design tool, I began by creating a wireframe to outline the core views of the application. From there, I iterated through multiple drafts, gathering feedback from stakeholders and refining the design into a final version. For consistency and polish, I worked with a senior designer to resolve finer details, but most of the structure and flow came from my drafts. I also relied heavily on features like auto layout and column grids to balance flexibility with precision, which streamlined the eventual development phase.

The final design flow was straightforward:

  • Search – Users could enter their VIN or select their vehicle by make, model, and year.
  • Battery Details – Once identified, the system displayed essential information such as battery model, capacity, and health metrics.
  • Compliance & Transparency – Additional data like battery composition and government compliance details were structured in tables and lists. More complex information, such as supply chain maps, was available in popup modals for a deeper dive.

This approach ensured that the application was both functional for engineers and user-friendly for consumers, striking the right balance between technical depth and accessibility.

Development

Because this was a brand-new project and served as a proof of concept (POC), every component of the application was created from scratch. The primary objective was to build something functional and flexible, not necessarily production-scale. This meant prioritizing clarity, maintainability, and extensibility over advanced optimizations.

At a high level, the system followed a client–server architecture:

  • A RESTful Spring Boot API on the backend.
  • An Angular frontend for the UI.
  • A single PostgreSQL database instance to store data.

Technologies like GraphQL, containerization with Docker, or distributed database systems were intentionally skipped at this stage, since the focus was on proving functionality and demonstrating feasibility for future iterations.

Frontend

The frontend was built in Angular, leveraging GM’s internal component library for consistency across applications. This library provided:

  • Authentication utilities (e.g., token validation, login handling).
  • Pre-styled UI components that matched the company’s design system.

On top of this base, I implemented:

  • Error boundaries & fallback states to handle cases where specific vehicle or battery data was missing (a realistic issue in production, since not all vehicles had complete datasets).
  • Suspense-like loading components for smoother user experience while waiting on API calls.
  • Custom layout components and style overrides to better align with the modern, sleek design we had finalized in Figma.
  • Different component views such as a map view or chart views (MapBox & Chart.js)

A critical technical decision was how to handle authentication between frontend and backend. The application used token-based authentication: once authenticated via the internal library, the frontend appended JWT-like tokens to each request, which the Spring Boot API validated before returning data. This kept the flow lightweight while aligning with GM’s internal security practices.

Backend

The backend was implemented using Java Spring Boot, designed as a straightforward REST API. Key aspects included:

  • Repository pattern to abstract database queries, making the system more modular and maintainable.
  • Controller endpoints with HTTP verbs mapped cleanly to operations:
  • GET /vehicles/{vin} → fetch vehicle & battery details.
  • GET /supplyChain/{batteryId} → return supply chain map.
  • POST /feedback → submit user or stakeholder feedback on the application.
  • Business logic functions to automatically determine eligible tax credit amounts and verify whether a battery passed government compliance checks.

Because this was a POC, caching and scaling strategies (e.g., Redis, load balancers) were not prioritized, but the API structure was designed in a way that could easily extend to microservices if future iterations required it.

Database

Finally, for the database aspect a dedicated PostgreSQL instance was set up for persistence. The database design focused on clarity of schema rather than performance optimization. The schema included:

  • Vehicles Table – storing identifiers like VIN, make, model, and year.
  • Batteries Table – capacity, chemistry type, health status, and compliance metadata.
  • Supply Chain Table – relationships mapping critical minerals to suppliers and countries of origin.

The Supply Chain table was by far the most challenging to design compared to the others, since it had to represent deeply nested data structures spanning multiple levels of a battery’s hierarchy—from the pack level, down to modules, and finally to individual cells. On top of that, modeling the battery creation process added another layer of complexity, as different stages of assembly could occur at separate locations depending on the supplier and manufacturing flow. Capturing these relationships accurately required careful schema design to balance flexibility with query performance.

To populate the database:

  • I wrote migration scripts to pull data from multiple scattered internal sources into the PostgreSQL instance.
  • For datasets that didn’t exist yet (e.g., supply chain details still under negotiation with third-party providers), I created mock data that followed the expected schema. This ensured the frontend and backend could be tested end-to-end without waiting on finalized data contracts.

An unexpected challenge arose with vehicle images as I couldn’t find a centralized CDN or storage bucket for GM’s vehicle images at the time. This meant I had to manually source images for testing and front-end mockups, which slowed development slightly but also revealed a potential infrastructure gap.

Final Thoughts

This project was a tremendous learning experience for me. On the technical side, it was my first time working with Angular and Spring Boot in an enterprise environment, which gave me valuable hands-on experience with widely used frameworks. I also gained exposure to the challenges of cross-team communication, particularly when coordinating with different groups to source the necessary data—a skill that proved just as important as the technical work itself.

What I appreciated most, however, was the sense of ownership I had throughout the project. I was able to follow the process end-to-end: from initial ideation and planning, to design and development, and finally to presenting the finished proof of concept by the end of the summer. Seeing a project move from an abstract idea to a working product within such a short timeframe was both rewarding and motivating, and it gave me confidence in my ability to take on complex projects in the future.

Thanks for reading. Cya 👋.