Mobile application allowing for the management of the innovative ZipChargeGo charger

In a nutshell

A mobile application with a backend server for managing ZipChargeGo, a portable energy storage unit and EV charging station in one. The MVP lets owners control the charging process, locate the device on a map and review its status and charging history, with the app talking to the device through the backend over OCPP.

Challenges

ZipCharge came to us with an unusual proposition. ZipChargeGo, described by its makers as a power bank on wheels, is a compact portable charger the size of a suitcase that lets drivers charge without fixed infrastructure. Our task was the software that puts the owner in control of it.

We worked in two-week iterations, each closing with a progress walkthrough with the client. The opening phase defined the MVP scope and the application architecture. UX research followed, then workshops with the client, and from the material gathered we produced the information architecture and proposed user flows as clickable wireframes. Once the mockups were accepted, mobile development began, with backend implementation running alongside it and detailed UI design feeding in as it was completed.

Our approach

The breakthrough came from a question about who the product is actually for. The initial assumption was straightforward: EV drivers. Workshops and moodboard sessions with the client pointed somewhere else – the device is more likely to be perceived as a smart home gadget than as a piece of charging equipment. That shift changed what the application needed to be and how it was designed, and it happened early enough to shape the product rather than force a rewrite.

Because the app is only as good as its link to the hardware, integration was the technical centre of the project. We designed it to be resilient to change on the device side, which turned out to be exactly what the situation demanded.

Delivering software ahead of the hardware

The application was built while the first two device prototypes were still being constructed. The first working prototype was integrated with the app two months after development finished, which meant the software had to be flexible at the moment of meeting real hardware and adapt quickly ahead of the first public showing. Planning for that gap, instead of assuming a finished device, is what allowed the launch to hold its date.

Outcomes