Client case study
BatteryCompany — a mobile battery storefront for 28 device brands

The problem
BatteryCompany sells replacement batteries for mobile phones, and the catalogue is where most storefront platforms start to strain. A battery isn't a single product; it's a part that's only correct for specific phone models, across brands including Apple, Samsung, Google Pixel, OnePlus, Motorola, Xiaomi, Oppo, Vivo, Realme, and others — roughly 28 brands in total. A generic e-commerce template treats that as one long, undifferentiated product list. Customers don't shop that way, and neither could the client's team, who needed to manage stock and pricing across that same structure every day.
On top of the catalogue problem, the client needed the storefront to support how their customers actually prefer to transact in this market: browsing and paying online for some, but messaging on WhatsApp to confirm a part or place an order for others. A platform that only supported one of those paths would have left real revenue on the table.
There was also an operational problem behind the customer-facing one. Whoever runs the catalogue day to day needed a way to add new device models, adjust pricing per brand, and keep stock accurate without waiting on a developer for every change — and without that admin work risking the storefront customers were actively using.
What we built
We built BatteryCompany.in as a storefront organised around the brand structure from the ground up, rather than a flat catalogue with brand filters bolted on. Customers can create an account and sign in, browse by brand, add items to a cart, and check out with pricing in INR. Once an order is placed, customers can track its status rather than emailing to ask where it is.
Alongside the customer-facing storefront, we built a separate admin application at admin.batterycompany.in. This is where the client's team manages the catalogue, brand structure, and store settings day to day — deliberately kept apart from the storefront codebase so that admin changes and customer traffic don't compete for the same surface area, and so the client's team has a dedicated, focused interface rather than a bolted-on dashboard.
For customers who'd rather message than click through checkout, we integrated a WhatsApp contact and ordering channel directly into the storefront, so that path is a first-class option rather than an afterthought pointing to a phone number in the footer.
Customer accounts were built with registration and sign-in from the start, rather than a guest-checkout-only flow bolted on later. That matters for a store like this one: a customer who bought a battery for their phone six months ago is a customer worth recognising when they come back for their next device, and order history only works if there's an account to attach it to.
Technical approach
The storefront runs on Blazor Server. We chose it specifically for a catalogue-heavy application like this one: state and rendering live on the server, so the catalogue, brand filters, and cart update over a persistent connection without shipping a large client-side bundle to every visitor on what is, for a lot of this store's customers, a mobile connection. It also let us keep the UI logic in C# end to end, which matters for a catalogue structure this specific — brand and model relationships are exactly the kind of thing that gets messy when business logic is split across a separate front-end framework and API layer.
The admin application is a separate ASP.NET Core project rather than a set of privileged routes inside the storefront. That separation means the two applications can be deployed, scaled, and secured independently: a spike in storefront traffic doesn't affect the admin team's ability to update stock, and an admin-side change doesn't require redeploying anything customer-facing.
Pricing throughout the storefront is handled in INR natively, rather than converted from a base currency at display time — a small detail, but one that avoids rounding inconsistencies between the catalogue, cart, and the final checkout total, which is exactly the kind of discrepancy that erodes trust in an online store.
Outcome
BatteryCompany.in is live in production and actively maintained by GreenFrog, with the storefront and admin application both in day-to-day use by the client's team. The brand-based catalogue structure and the WhatsApp ordering channel were both direct responses to how this client's customers actually shop, rather than default e-commerce features included because a template shipped with them.
