Introduction

BotOn started as a connected vehicle platform inside B4Motion, a venture builder focused on mobility. The product solved a real operational problem: making raw vehicle telemetry understandable and actionable for fleet operators. In 2022, Astara acquired B4Motion. BotOn became Astara Connect, gaining access to Astara’s OEM network and the commercial infrastructure.

I joined during the BotOn phase, leading a full redesign of the platform. Shortly after, I led the rebranding to align with Astara’s visual identity.

⬇ Astara Connect Platform after redesign.

My role covered product design end to end: research, feature definition, design system, engineering support, and cross-functional alignment with product, business development, and the technical team.

The platform’s connected-vehicle capabilities were later extended directly to end users through Mercury, a white-label platform for connected vehicle access.

Discovery

Our initial customer was an internal vehicle subscription service requiring monitoring capabilities: real-time location tracking, proactive maintenance notifications, and remote engine immobilisation in response to payment defaults.

As the platform grew, new customer profiles emerged with different needs but the same underlying problem. New companies needed vehicle tracking to post-sales services and drive scoring reports to assess driver behaviour and adjust risk models.

Key inputs that shaped the direction:

• Regular customer conversations with fleet managers and operators across the Astara ecosystem, OEM corporations, and other companies (Insurance, Rent-a-car, …)
• Competitive analysis of connected vehicle platforms and fleet management tools
• Vertical stakeholder alignment (mobility and EV services) with business development to understand which new verticals and brand integrations get more impact

Across these conversations, the same pattern kept surfacing: a fragmented sector, moving fast, where EV and mobility services lived in disconnected silos instead of a single view of the vehicle. The problem wasn’t adding another monitoring feature, it was building the all-in-one layer that unified those silos as the sector kept evolving.

Framing

The core design challenge was translating data availability into decision support at scale. The platform could ingest telemetry from any connected vehicle via OEM cloud or hardware integration, but value was focused on surfacing the right data to the right operator at the right moment.

Four strategic priorities structured the product direction:

• Scalable fleet visibility. A monitoring architecture supporting fleets from 10 to 10,000+ vehicles, with configurable alert logic requiring no engineering intervention per deployment
• Automated reporting outputs: drive scoring, kilometre summaries, and maintenance indicators formatted as exportable, client-facing deliverables rather than internal dashboards
• Rebranding as product infrastructure. The BotOn-to-Astara Connect transition established the commercial and technical foundation for OEM integrations and third-party services that were inaccessible initially
• API-first architecture and developer portal to enable integration into any third-party system. A dedicated developer portal provided self-service access to authentication flows, endpoint documentation, sandbox environments, and integration guides

GDPR by design was a non-negotiable constraint across all four priorities. This boundary was not a compliance response but a core product principle, enabling commercial deployment across regulated markets without per-market legal overhead.

The alternative we discarded was continuing to build ad-hoc, client-specific solutions, the direction several early B2B engagements with Mercedes-Benz and Mapfre had pulled the platform toward. Each one absorbed a disproportionate share of Astara Connect’s engineering capacity to meet a single client’s requirements. Deprioritising that path freed the team to invest in the four priorities above instead.

Crafting

Redesign and rebranding

The BotOn interface had grown organically around its first use case. The redesign addressed structural information architecture issues: how vehicles were grouped, how alerts were surfaced, how data density was managed across different screen contexts.

Configurable notification system

The fleet monitoring layer required operator-defined threshold configuration: geofencing boundaries, inactivity windows, battery levels, engine immobilisation triggers. The design abstracted configuration complexity behind a structured setup interface accessible to non-technical fleet administrators.

Reporting and drive scoring layer

Telematics data was translated into structured reporting outputs for several clients: driving behaviour pattern analysis, cumulative kilometre summaries, ESG reports, and risk indicators. Report formats were designed for direct client presentation, eliminating manual post-processing by Astara Connect’s operations team.

Developer experience and portal design

In close collaboration with the engineering team, we designed the developer portal as a product in its own right. Clear API response specifications, interaction models, and error state documentation reduced integration cycle times and removed engineering bottlenecks from the client onboarding process.

Design system and engineering alignment

A component library maintained in Storybook and beta environments served as the shared reference between design and engineering.

Validating

Astara Connect scaled from a single internal deployment to a commercially distributed multi-vertical product:

• ~5,000 connected vehicles under active management
• 24 clients across fleet subscription, OEMs, and other verticals
• Multiple OEM integrations unlocked through the Astara acquisition, extending addressable market coverage beyond BotOn’s prior reach
• 5 automated report types available to clients for fleet monitoring, including a dedicated ESG report, each customisable and downloadable without engineering involvement

Reorganising the API documentation into a single reference, endpoints, authentication flows, request recipes, and sandbox guides, turned the developer portal into the primary way new integrators understood the product, instead of walking each one through it manually.

Reflection

Framing the rebranding as a product infrastructure decision created internal alignment around the iPaaS positioning that had a clearer commercial narrative for business development, and a more coherent product north star for the engineering and design teams.

The reporting layer illustrates a pattern worth replicating. A specific client request became a reusable product capability that opened a new commercial vertical. That direction requires deliberate product thinking at the framing stage, not at the delivery stage.

What I would do differently:

• A structured customer feedback cadence earlier in the process.
• Insight generation was disproportionately dependent on informal account management conversations.
• A systematic feedback protocol would have accelerated the identification of cross-vertical patterns and tightened the loop between customer need and roadmap prioritisation.