Introduction

Astara Connect needed to extend its connected vehicle capabilities directly to end users. The challenge was building a platform architecture that could serve two fundamentally different use cases simultaneously:

• Driver app for end users of brand partners (B2C).
• Fleet management product for companies, enabling an internal booking manager and a driver app for internal fleets (B2B and B2B2C).

Both had to run on the same infrastructure, with full white-label flexibility, while ensuring that driver data never retrieved at the Astara Connect’s systems, keeping GDPR obligations where they belonged with the brand managing the relationship.

My role covered the full product scope across both lines, from initial research and framing through to delivery and engineering support. I worked directly with the CPO, lead PM, and a cross-functional team of two developers and a business development lead.

Discovery

In stakeholder conversations, every brand in the Astara ecosystem had different technical capabilities, different end-user relationships, and different tolerances for data ownership. And in the technical layer, vehicle connectivity varied significantly across markets, inconsistent network coverage and communication latency between the app and the vehicle meant the interface had to work reliably in degraded conditions, not just ideal ones. A command sent from a phone couldn’t assume an immediate response from the car.

Key inputs that shaped the direction:

• Stakeholder interviews with brand partners to understand their technical constraints and go-to-market needs.
• Competitive analysis of existing connected vehicle solutions, most required deep native app integration, which excluded smaller brands.
• Regulatory review of GDPR implications across different data architecture models.
• Technical exploration of keyless access scenarios, understanding how vehicle hardware capabilities varied by brand, and where third-party hardware could fill the gap.

The insight that changed the framing: the problem wasn’t “how do we build a driver app” — it was “how do we build a platform any brand can activate in days, for any use case, without inheriting our compliance obligations.”

Framing

The core architectural decision: personal data, the relationship between a vehicle and its driver, had to remain with the brand, not with Astara Connect. Astara Connect would manage all vehicle data and technical infrastructure invisibly in the background. This single constraint shaped every product decision that followed and made the platform commercially viable across markets.

From this framing, the platform supported two parallel product lines:

B2C — Driver product

A white-label web app, embeddable and fully customizable via CSS variables, activatable per brand. Starting as a web MVP to validate the concept, with the roadmap pointing toward a native app once the proof of concept passed.

B2B — Fleet management product

A booking management application for companies with internal vehicle fleets. An internal company employee acted as administrator, managing vehicle availability, reservations, and access, while drivers received time-bound access via email communications. Keyless access was handled in two ways: natively for brands with integrated vehicle capabilities, or via additional hardware for vehicles without built-in connectivity, enabling Bluetooth-based access in both cases.

The alternative we discarded was a single Astara-branded app with multi-brand support. Simpler to build, but it would have required Astara to hold GDPR relationships for all end users across all markets, not viable at scale.

Crafting

White-label flexibility

The platform used a token-based styling system. Brands could control colors, typography, and logo without touching the underlying components. The same codebase rendered as Mitsubishi in Chile or EVxperience in different markets, and the same architecture underpinned both B2C and B2B deployments.

Keyless access in low-connectivity scenarios

The most technically demanding design challenge was keyless access without network coverage. The interface had to communicate vehicle state clearly in conditions where real-time feedback wasn’t available, making status communication and error handling critical design decisions.

REST API for native integrations

For brands with existing native apps, a REST API exposed vehicle commands( lock, unlock, engine control) allowing them to integrate Astara Connect capabilities directly without adopting the white-label web app.

From web MVP to native app

The B2C web app served as the proof of concept. The B2B fleet product could be commercialized alongside either the web app or the native app depending on the brand’s needs. For the REST API and token architecture, I worked closely with the engineering team defining interaction models, API response specifications, and the data structures that would affect the end-user experience downstream.

Validating

Validation happened in two layers. The first was operational gathering real user feedback on the remote locate and lock flows and iterating on edge cases: poor connectivity, delayed API responses, ambiguous vehicle states.

The second was architectural, each new brand activation tested whether the white-label system delivered on its promise of flexibility without fragmentation.

By the end of the project the platform supported:

• 3 brand activations across different markets using the web app and 1 native app deployed in Europe and Latam
• 344 connected vehicles managed through the platform
• 48 bookings per month processed through the booking management application

Each successive brand activation required less engineering effort than the previous one, a clear signal that the system was working.

Reflection

What worked well was the decision to frame the problem architecturally from the start. The GDPR constraint that initially felt like a blocker became the design principle that made the system scalable and keep Astara Connect privacy argument as a principle. That framing shift, from “driver app” to “activatable white-label platform”, is what made the product valuable beyond the first use case.

What I’d do differently, it was to invest earlier in documentation for brand partners. The Help Center content came late in the process and required significant reactive effort. An onboarding kit defined during the framing phase would have reduced the engineering support load and accelerated brand activations, though it wasn’t a stopper to taking the project to the next step.