How to make infotainment an EV ally

It started with frustration. Like many EV enthusiasts, I loved my electric car until the infotainment system began testing my patience. Limited features felt like the software hadn’t caught up with the rest of the car. So I did what engineers do: built something that met my needs better – the Happy Tesla Dashboard.

It turned into more than a side project. It showed me, first-hand, how genuine domain passion and clear priorities can make things work.

When infotainment stops being fun

Ask anyone who spends enough time with electric vehicles, and you’ll likely hear a quiet sigh when the topic turns to infotainment. It’s not that the systems are bad; they just rarely live up to the expectations the rest of the car sets. An EV that accelerates like a spaceship shouldn’t have an interface that behaves like an old printer.

No wonder it has been a recurring theme across the e-mobility software industry. A few years ago, Volkswagen had to postpone the ID.3 launch because the software wasn’t ready, and Volvo later faced a similar moment when the EX30 owners claimed refunds after over-the-air updates caused glitches in their vehicles. Neither case broke the world, but both showed how fragile and interconnected vehicle software has become.

Infotainment is no longer an isolated Human–Machine Interface (HMI) layer. In most EVs, it connects navigation, media, diagnostics, battery management, connectivity services, and over-the-air updates. As McKinsey noted, a modern car contains over 150 million lines of code, spread across 70-100 Electronic Control Units (ECUs), and infotainment touches many of them. That means a single failed update can affect multiple systems at once.

It also explains why customers often lose patience faster than developers can deploy patches. J.D. Power’s 2024 Tech Experience Index (TXI) Study reported that infotainment and connectivity features, such as voice recognition and touch controls, are one of the most problematic technologies for new-vehicle owners, including EV drivers.

The Happy Tesla Dashboard: frustration turned into code

Happy Tesla Dashboard runs directly in the car’s browser, and no installation is needed. It brings together the things drivers actually reach for: Spotify playlists, Netflix for charging stops, weather updates before long drives, and a quick peek at diagnostics.

But the project quickly grew beyond the basics and evolved into a genuine entertainment and information hub with access to major streaming platforms, a curated feed of Tesla news, integrated maps, favourite games, and even a smart garage and gate opener. The interface also adapts to conditions through an automatic day/night mode, making the screen easier on the eyes whether you’re driving at noon or at midnight.

None of it is flashy – it is just the kind of tool engineers build when they are tired of waiting for someone else to fix it. And that gave me a glimpse of what can happen when people who understand the problem also enjoy solving it.

Technically, it’s simple by design. The dashboard runs on standard web technologies, isolated from the vehicle firmware. That separation means no safety-certification overhead and zero risk to core systems.

Over time, the dashboard also grew more intelligent. It now connects with Tesla’s onboard diagnostics to surface basic vehicle-status insights directly in the interface. And new features are already in development: intelligent battery-preconditioning triggers and detailed battery-parameter statistics to get deeper insight into how the EV behaves in real-world conditions.

Lessons learnt

Working on this small project reminded me how much freedom comes from building something outside the production bubble. When you’re not waiting for validation rounds or safety reviews, you can test, break, and fix things in a single afternoon – and that’s where real learning happens.

I also experienced how powerful early simulation can be. Running user flows in a virtual setup before touching firmware saves a surprising amount of time and frustration later on.

Not every layer needs the same level of scrutiny either. Systems that affect safety should move slowly and predictably, but things like entertainment or personalisation benefit from faster cycles and a bit of experimentation.

And, as always, the clean interfaces make or break a project. Also, good APIs are what keep you safe when you move fast – they’re the invisible contracts that let teams innovate without stepping on each other’s code.

Beyond bugs and updates

It’s tempting for programmers to talk about infotainment as a pile of code, updates, and (occasionally) bugs. But what drivers really notice isn’t the code, but the feeling of using something that seems to understand them.

The delay when switching songs, the map that forgets your last destination, the weather app that takes too long to load – these small things define the experience.

That’s where empathy meets engineering. I built the dashboard because, as an EV driver, I knew the context first-hand. And that perspective can be part of larger projects, too.

In my countless conversations with other Tesla owners, the message was the same: they didn’t want a complex system, they wanted a smarter one. A dashboard that launches instantly in the browser, lets you log into your streaming services, checks the weather before a long trip, opens your garage door when you get home, and displays useful car data. Lightweight, practical functionality that feels obvious once you have it – but rarely comes built-in.

When the core team is busy with vehicle software and safety, it helps to have external specialists who know the domain and can explore, prototype, and discover what’s genuinely worth scaling.

Sometimes, this kind of flexibility comes from team augmentation – bringing in experts from a staff augmentation company that understands both software and eMobility. It’s often the fastest way to validate ideas without slowing the main production flow.

Infotainment done right: a few simple rules

After a few years of exploring infotainment issues, I’ve spotted some patterns:

• Prototype quickly, test early. Even browser-based mockups can reveal usability issues long before anyone touches production code.
• Separate UX from safety-critical firmware. Keep the UI logic away from powertrain or safety systems – that’s how Tesla, Rivian, and Polestar manage faster, safer release cycles.
• Test every over-the-air update as carefully as a full release. It’s the only way to avoid “Volvo EX30”-type issues.
• Mix internal and external skills. Let core teams focus on compliance, architecture, and diagnostics, while external partners bring UX, data, or web know-how for non-critical layers.

Even the big manufacturers are starting to think this way. Volkswagen’s CARIAD brought in Luxoft engineers to speed up cockpit development. Volvo partnered with Epic Games to build the next generation of dashboard graphics. BMW works with KPIT specialists on connected-car systems – all part of a broader eMobility ecosystem.

Conclusions

Happy Tesla Dashboard was a small, focused experiment, but it proved that modern infotainment sits at the intersection of technology, empathy, and speed. Whether you’re part of a large OEM or a startup working on EV software development solutions, you need to know when to experiment and when to stabilise.

Fast iterations, modular design, and smart use of outsourcing models can help teams stay lean and creative. Sometimes the best outcomes happen when engineers step outside the strict production cycle, validate ideas, and then bring them back stronger.

If you’re exploring eMobility software development, think of infotainment as more than an HMI!

FAQ

1. Why do EV infotainment projects fail?

Often because they’re managed like hardware projects, not software ones. When development follows slow approval chains and scattered ownership, even simple fixes take months. A focused, cross-functional team – whether internal or external – can test, learn, and adapt faster.

2. What’s the biggest challenge in building eMobility software today?

System integration and coordination. When multiple teams handle different parts of the system, communication gaps lead to delays and bugs. The most effective EV software teams increasingly rely on modular design and clear APIs to keep the whole vehicle connected and manageable.

3. Can staff augmentation really help with infotainment or UX projects?

Yes, especially when it’s focused on the right areas. Infotainment and UX evolve quickly, and internal teams often can’t spare time for small improvements. Staff augmentation for e-mobility lets you bring in designers or front-end engineers for short, focused tasks while your core team stays on safety and compliance.

4. What’s the right balance between in-house vs outsourcing?

It comes down to stability and speed. Keep powertrain, safety, and diagnostics in-house because those systems need full control and predictable release cycles. Use team augmentation for faster-moving areas like UX, data, or integrations. The best inhouse vs outsourcing balance isn’t fixed; it adapts to your current needs.

5. How can smaller EV software companies compete with OEMs?

By being faster and more adaptable. Big manufacturers move slowly because of complex approval chains and legacy systems. Smaller teams can iterate and test new ideas quickly, often bypassing the heavy internal structure that slows larger organisations down.