Platform evaluations tend to spend most of their time on the operator dashboard - monitoring, tariffs, reporting - and a few minutes at the end on the mobile app. That ratio is backwards relative to what the app actually decides. The dashboard is used by a dozen internal people who will learn whatever they're given. The app is used by every customer you have, it's the only part of the stack carrying your brand into someone's pocket, and it's where drivers quietly decide whether to come back.
The five jobs a driver app has to do
| Job | What it needs | What it costs when it's missing |
|---|---|---|
| Find a working charger | Map discovery with live availability, filters, route planning | Drivers arrive at an occupied or faulted connector and blame your brand, not the charger |
| Start a session | QR scan or in-app start, with a reliable fallback when one path fails | The single most common support call, and the one that loses first-time users outright |
| Pay without thinking about it | Saved cards, e-wallets, local methods, prepaid wallet with top-ups | Payment friction at the connector, which converts worse than anywhere else in the funnel |
| Prove what happened | Live kW and cost during the session, history and receipts afterwards | Billing disputes that consume support time and require manual session lookups |
| Come back | Push notifications, promotions, loyalty tiers, in-app support | A network that acquires drivers repeatedly instead of retaining them |
The first session is most of the funnel
A driver standing at a connector with a nearly flat battery is the least patient user your product will ever have. Anything between arriving and drawing power - an account to create, an email to verify, a card to type in - is a place to lose them, and a lost first session is usually a lost customer. This is why guest charging matters even for networks that want app installs: let the driver scan a QR code, pay, and charge without an account, then invite them into the app once the car is actually charging. The install decision goes much better when it's an offer rather than a toll gate.
Live session feedback is a support feature
Showing live kW and accumulated cost while the session runs looks like a nicety and behaves like a cost-control measure. A driver who can watch power being delivered doesn't call to ask whether charging started. A driver who can see the rate they're paying, and later a receipt that matches it, doesn't open a dispute. The same logic applies to idle fees or time-based components in your tariff - they only work if the app shows them coming, which is the practical constraint behind choosing a tariff model.
What “white-label” needs to actually cover
White-labeling an app is not just a colour palette and a logo. The questions that matter are about ownership and ongoing operation:
- Store presence. Is it your own App Store and Play Store listing under your brand, or a shared app with a tenant switcher inside it? Only one of those makes your network searchable by name.
- Releases and OS compliance. iOS and Android ship breaking changes and new store requirements every year. Someone has to own that work forever - if it isn't the vendor, you've hired a mobile team without deciding to.
- Configuration vs. custom engineering. Branding, tariffs, payment methods and promotional campaigns should be configuration. If each is a change request with a quote attached, your marketing cadence is now gated on the vendor's release schedule.
- The same data as the dashboard. If the app reads a replica rather than the live session record, your support team will eventually be looking at a different number than the driver is - see why one session record matters downstream.
Questions worth asking before signing
- Whose developer account holds the app, and what happens to the listing and its reviews if we change vendors?
- Which local payment methods are supported today, in our market, in production - not on a roadmap?
- Can we run a time-limited promotional campaign without waiting on an app store review?
- Can a driver charge and pay without installing anything, and convert to an account afterwards?
- Who handles app store rejections, OS deprecations and SDK updates, and at what cost?
CarChargeOS ships native iOS and Android apps under your brand, on your store listings, against the same real-time platform data the operator console uses - see the Experience layer on the platform page, or the full white-label scope in white-label vs. single-brand CSMS.
Frequently asked questions
Do we need a mobile app at all if we support QR guest charging?
You can operate without one, but you give up the retention layer entirely - no push notifications, no saved payment method, no loyalty, and no direct relationship with a repeat customer. Guest charging is the right entry point for a first session; the app is what makes the tenth one likely.
Is a white-label app worse than a custom-built one?
On the features drivers actually use - discovery, start/stop, payment, history - a mature white-label app is usually ahead of a first-generation custom build, because it's been through years of real sessions and store reviews. What you trade away is unlimited freedom over flows the platform doesn't expose, which is the same trade as build vs. buy vs. white-label generally.
How do app updates work when the platform vendor owns the codebase?
The vendor builds and submits releases on a shared train, so feature work and OS-compliance updates reach your app without you managing a mobile pipeline. Branding, tariffs and campaigns change as configuration - which is what keeps day-to-day marketing off the release schedule.