This project tackles a common business challenge: transforming a complex, raw dataset into an accessible web application that provides actionable insights. This article documents the end-to-end process of building a full-stack battery analysis dashboard with Django and React.

Live Demo: ul-battery-performance-project.web.app
Frontend Repo (React): GitHub
Backend Repo (Django): GitHub

Core Technologies: Python, Django, Pandas, PostgreSQL, React, Material-UI (MUI), Docker, Fly.io, and Firebase Hosting.

Part 1: The Challenge: From Raw Data to Actionable Metrics

The project began with a open-source dataset from UL Research Institutes on the cycle life of 21 batteries. The raw Excel files were composed of 1,591,470 data points and no clear insight. My first goal was to make sense of the data and present it in a way that could make sense to a diverse audience. I decided to figure out which of the batteries were the 'best' and to rank them in order.

To make the data useful for decision-making, I translated the raw numbers into key business metrics:

State of Health (SOH): The first and most crucial metric. I calculated this as a percentage by comparing a battery's final discharge capacity to its initial capacity: (Last Cycle Capacity / First Cycle Capacity) * 100.
Durability Score: A custom score weighted heavily towards the total number of cycles a battery could endure before failing.
Resilience Score: A score weighted towards a battery's ability to maintain a high State of Health, even under stressful test conditions.
Balanced Score: An overall score giving equal weight to both Durability and Resilience.

With these metrics defined, I had a clear goal: build an application to calculate these scores and present them in a clean, ranked, and interactive way.

Part 2: The Technical Solution

With a clear data strategy I moved on to the technical implementation, splitting the project into a dedicated backend and frontend.

The Backend: A Django & Pandas Powerhouse

For the backend, I chose Django and Django REST Framework to build a robust API. The primary goal was to take the scattered source files and create a clean, reliable single source of truth.

To accomplish this, I created a custom management command that uses the Pandas library to automatically:

Unify data from 21 different multi-sheet Excel files.
Process over 1.5 million raw data points into a consistent and structured format.
Enrich the data by calculating and appending key performance indicators (SOH, Durability, etc.) to each record.

The final processed data is saved to a production-grade PostgreSQL database. This ensures data integrity and allows the API to serve fast, reliable information to the frontend.

The Frontend: An Interactive React Dashboard

For the frontend, I used React with Vite for a fast and modern development experience. To create a polished and responsive UI, I chose Material-UI (MUI).

The interface was built around a few key components:

A set of filter controls to switch between the Durability, Resilience, and Balanced rankings.
A grid of BatteryCard components, each displaying a battery's key metrics and its rank for each performance tier.
A client-side caching system. On page load, the app makes a single health-check call to the backend. If the data on the server has not changed since the user's last visit, the app loads the data instantly from the browser's cache. This caching strategy results in near-instant load times for repeat visitors and reduces server load.

Part 3: Deployment & Key Challenges

Building an app locally is one thing; deploying it to the world is another. This is where the most valuable lessons were learned. I chose Fly.io for the Django backend and Firebase Hosting for the React frontend.

The journey involved solving several classic deployment challenges:

Dependency Hell: The initial fly deploy failed repeatedly. The cause was a mismatch between my local Python environment and the production Docker environment on Fly.io. Old versions of packages like numpy and Pillow in my requirements.txt were incompatible with the server's Python 3.13. Furthermore, packages with system-level dependencies like pygame (which was unnecessarily included) required me to manually add libraries like libsdl2-dev and libfreetype6-dev to the Dockerfile. Solution: I cleaned my requirements.txt meticulously, removing unnecessary packages and un-pinning versions to let the build process select compatible ones.

Pro Tip: To create a truly clean requirements.txt, I deleted my old virtual environment, created a fresh one, and installed only the essential packages. Then, after running my scripts locally to find any missing optional dependencies (like xlrd), I ran pip freeze to generate a perfect, production-ready file.
The Out-of-Memory Crash: My initial data loading script, which worked fine on my laptop, consistently crashed the small free-tier server on Fly.io because it ran out of memory. Solution: I refactored the process. I ran the heavy calculations once locally and saved the results to a simple summary.csv file. I then created a new, lightweight production script that only reads this pre-calculated file. This separated the heavy data processing from the production deployment, making it fast and memory-efficient.

Final Results & Key Takeaways

The result is a performant, scalable, full-stack application that successfully transforms raw scientific data into actionable insights for end-users. This journey reinforced the importance of not just writing code, but understanding the entire lifecycle of a data product from analysis and processing to deployment and real-world problem-solving.

Key Achievements:

Engineered a data pipeline using Python and Pandas to process over 1.5 million raw data points into actionable business metrics.
Developed and deployed a full-stack application featuring a Django REST API on the backend and a responsive React UI on the frontend.
Implemented a robust client-side caching strategy that improved repeat load times by over 90%.
Managed a real-world cloud deployment to Fly.io and Firebase, successfully troubleshooting complex dependency and server memory issues.

Thank you for reading my case study. If you have any questions or would like to discuss my work further, please reach out on LinkedIn. You can also view more of my projects on my github.