Introduction

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

• Driver app (B2C).
• Fleet management services for companies (B2B).

Both services ran on the same infrastructure, with white-label flexibility, ensuring driver data never reached Astara Connect’s systems.

My role covered the end-to-end process, from initial research and framing through to delivery and engineering support. I worked directly with the CPO, 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 capabilities, different end-user relationships, and different tolerances for data ownership. On the technical layer, vehicle connectivity varied across markets: inconsistent network coverage and latency between the app (digital environment) and the vehicle (physical environment) meant the interface had to work in degraded conditions, not ideal ones.

A command sent from a phone couldn’t assume an immediate response from the car.

Key inputs for shaping the direction:

• Interviews with vehicle brands to understand their technical constraints and go-to-market needs.
• Competitive analysis of existing solutions, most centered on native app integration, which excluded smaller brands.
• Regulatory review of GDPR implications across different data architecture models.
• Exploration of keyless scenarios to understand integrated hardware capabilities by brand.

This wasn’t about building an app. It was about building a platform that any brand could activate and customize in days, adaptable to any market and use case, without inheriting Astara’s data privacy obligations.

Framing

The core architectural decision: driver data had to remain with the brand, not with Astara Connect. Astara Connect would manage all vehicle data and technical infrastructure in the background.

This single constraint shaped every product decision that followed and made the platform viable across markets.

From this point, the platform had to support two product lines:

B2C — Driver app

A white-label web app, embeddable and fully customizable via CSS variables, adaptable 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 fleets. Enabling internal user roles, managing availability, reservations, and vehicle access. 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 imagery without touching the underlying components. The same codebase rendered as Mitsubishi in Chile or Astara EV-xperience 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:

• An operational solution by gathering real user feedback on the booking communications, the remote locate and lock flows and iterating on edge cases: poor connectivity, delayed API responses, or ambiguous vehicle states.
• An architectural solution, 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 framing 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 kept Astara Connect’s 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 would do differently is 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.