I Built a Powerbank-Sharing Startup Alone — and Today I'm Shutting It Down

Today I'm switching off the server. This is the end of the journey for ChargeBro — and a good moment to recap and write down the lessons learned.

The idea

In December 2019, while travelling in Thailand, I first heard about powerbank sharing. I've never tried it before, but the idea stuck: scan a QR code, take a charged powerbank, and return it later — sometimes somewhere else. It solved a small but real problem at the exact moment you needed it.

Back in Ukraine, I couldn't stop thinking about it. At the time, we didn't have anything like that locally. The idea sat in my head until COVID lockdowns arrived and private life slowed down. I needed inspiration—something messy and real.

That's how ChargeBro started: a powerbank-sharing "startup" built by one developer, mostly at night, during a year when the world was paused.

My first Git commit is dated June 10, 2020. I didn't know native iOS or Android development, but I was reading a book about building an Uber clone with Codename One, and it inspired me so much that I decided to build the whole thing myself. I believed I could ship a mobile app without becoming a Swift/Kotlin developer first. That belief was naïve in some ways, but it removed the biggest obstacle: hesitation.

Naming made it real

The first working name was takeAndCharge. Then I shared the idea with a group of friends and, in a very informal setting, we started brainstorming names and slogans. Nothing structured — just jokes, ideas, and "what if we call it…?"

"ChargeBro: charge in time — no stress to find"

I checked domain availability. It was free, so it won.

The hardware: six powerbanks and a SIM card

I searched for hardware and ended up ordering a powerbank station from China. No screen — just a compact unit with six powerbanks, each with multiple built-in cables, plus a SIM-based internet module.

A sample arrived. I installed a local prepaid SIM, modified the device configuration, and started writing the backend that could speak the station's protocol.

Backend was fast

Backend development is my full-time job. I already had solid experience, so it took me a few weeks to build a working draft.

As hosting, I considered AWS first because I knew it well from work. But for a pet project it was overkill — both in cost and complexity. I rented a small Hetzner server, used Dokku, and deployed a Spring Boot service. Swagger became my "control panel." When you're operating alone, being able to test and tweak quickly matters more than elegance.

The full system diagram, code structure, and deeper engineering notes are in the backend repo README

The stations had random reconnections. I never fully proved why — carrier conditions, firmware instability, power issues, "all of the above."

I built online/offline status with a small delay, a map overlay to prevent users from walking to a dead station, and automatic admin alerts to my phone whenever something happened.

The mobile app: where 80% of my time went

Backend was familiar. Mobile was new, challenging and pure fun.

I decided to centre the app around a map: find stations, scan QR, unlock, and track the rental. I started with Figma mocks, showed them to a couple of friends, made fixes, and then started coding.

At one point, I spent two weeks polishing a splash screen animation: the logo appears, grows, fades into the map, and other elements appear. I proudly launched the empty app in front of my girlfriend after saying I had added a new feature.

She watched it and said: "Okay… so where is it?"

I said: "That was it."

She laughed. "So that's what programmers do," she said.

The first pilot

By December 8, 2020, I installed the first working station. The first real pilot happened through the most startup-like channel possible: I talked about the project to friends, and a friend-of-a-friend worked with a gym administration in Kyiv.

No official partnership. No payments at first. Just: "Let's try it."

I installed one station at the front desk for gym members. Soon, the gym's other two locations wanted stations too.

That's when it stopped being "a hobby project" and started acting like a startup. I monitored logs daily, watched every rent and return and fixed issues on the fly.

Support also became a real problem. Stations went offline, deposits didn't release instantly, and sometimes users couldn't unlock a slot on the first try. That's why I added a dedicated Support button in the app: it redirected users straight to a chat with my bot, which routed the message to me. I also left my phone number there—because when you're dealing with real users and real money, fast response matters more than perfect UI.

And yes—more than once, I was debugging a station connection from my phone while someone was standing at the gym front desk waiting.

Mutual trust

So even though I started as a fun non-profit experiment, I had to design for fraud from day one. My solution was intentionally small: a 50 UAH pre-authorization hold, released automatically after the powerbank was returned. The amount was less than the powerbank itself. The point wasn't full insurance — it was friction against casual fraud and a "don't do something stupid" signal.

But theft prevention has a cost: trust. In Ukraine back then, powerbank sharing was a new category—most people had never used anything like it. The moment the app asked for a card, a lot of users hesitated: "What if my card gets charged?" or "What if the deposit doesn't come back?" Others simply didn't want to spend time registering for yet another app. In the gym pilot, that friction kept usage modest—around 1–2 rentals a day.

People don't adopt your product because it works; they adopt it because it feels safe and effortless.

If I built it again, I would simplify onboarding aggressively: phone number + SMS login (no email/password), deposit via Apple Pay / Google Pay, and probably a web-first experience — because apps add install friction, update friction, and store policy friction.

iOS was stricter (and shorter-lived)

Android felt easier. iOS was slower to approve and earlier to remove. In the end, both disappeared because I wasn't maintaining them, and store policies evolve.

That's another practical reality of "shipping a product": publishing is not a one-time event. It's a long-term maintenance commitment.

Shipping was possible. Scaling alone wasn't.

Technically, ChargeBro worked. I integrated hardware, ran a TCP station protocol server, built a backend, shipped a cross-platform app, deployed stations, and operated a pilot.

But while I was engineering, I wasn't doing the other half: partnerships, distribution, sponsorships, fundraising. And then the market moved. A competitor later launched with broader coverage and real marketing, and I understood the truth:

You can build a product alone. You cannot build a company alone — especially when it depends on physical deployment, venue relationships, and user trust at scale.

Why I made the repos public

ChargeBro is no longer active, but it’s still one of the most educational projects I’ve ever built—because it forced me into real-world constraints: unreliable hardware connections, trust issues, and the gap between a working demo and a working business.

I’m publishing the code not because it’s perfect, but because it’s honest. If you’re a developer thinking about building something physical, this is your reminder: you can. You’ll learn fast.

The backend includes custom binary protocol handling (station ↔ server), a two-phase payment flow (pre-auth + release), and real-time bridging from station TCP events to WebSocket updates for the mobile clients. The “frontend” is a cross-platform Java mobile app (published on iOS and Android in the past) with the original UI flows and assets—things you rarely see in tutorials. Just don’t confuse shipping with scaling.

Repos: chargebro-mobile and chargebro-backend