Deep Tech & Advisory
PurismEV
This chapter was a mix of technical advisory and some R&D collaboration. I mainly helped with strategy, business model, and technical-feasibility questions, while also contributing to core IoT algorithm work and AI battery-efficiency research.
Role
Technical Advisor / Strategy, Feasibility & Algorithm Collaboration
Client
PurismEV
Industry
Smart Mobility / AI Powertrain / IoT Systems
Outcome
Helped the team turn a fairly wide set of energy, charging, and IoT / AI ideas into a clearer product direction that was easier to explain to the market.
Strategy + R&D
What I mostly did here was help the team make the path clearer
What the public sees is PurismEV's IEMS, AI powertrain, and AIoT story. My own part was mostly around strategy, business model, technical feasibility, and some of the core algorithm work. I was not building the whole thing, but I did get to help at a few important points.
Vehicle Prototype
That is part of what makes this space interesting. Things that sound reasonable on slides often need to be reprioritized once they hit a real vehicle, battery, and control stack.
public efficiency gain
40%+
EV platforms tested
10+
go-to-market
OEM + Fleet
Case Study Summary
>PurismEV shows how I work as a dense technical advisor inside smart-mobility and energy-optimization systems, not only as a product builder.
>The case is useful for understanding how to break down complex hardware, vehicle, and data-layer questions.
>Its value is in deep-tech judgment and productization pacing rather than a single feature win.
Who this case is for
>Smart mobility, AIoT, and energy-system decision makers
>Teams needing high-context technical advisory support
>Builders exploring how deep-tech programs become products
Key outcomes
>Helped clarify architecture choices across vehicle, fleet, and energy-management layers
>Created sharper product layering inside a multi-module, multi-data-flow system
>Improved technical decisions by tying them more closely to commercialization pace
Key constraints
>Boundaries between hardware, vehicle control, and data services are easy to blur
>Deep-tech programs are constrained by supply-chain and validation cycles
>Productization pace is usually slower than in software-only environments
Repeatable patterns
>Clarify module responsibility before debating overall system direction
>Use data flow and operating context to define product layers
>Turn advisory work into executable decision frameworks instead of abstract commentary
FAQ
The issue was not a lack of options. It was having too many possible directions, and deciding what should go first.
Short version: the hard part was not a lack of direction. It was having too many directions that all sounded reasonable.
Battery behavior, motor efficiency, throttle control, IoT data, fleet management. Each of these can make sense on its own. The problem is that a startup cannot push everything at once. Deciding what to prioritize and what to leave for later becomes the real challenge.
We were also very clear about one thing from the start: electric mobility is going to be a huge trend. But if you look at the market, not many teams are actually doing a great job on battery and vehicle optimization together.
And that is where the harder part begins. It is not enough to say, "our technology can improve this." You also need to show customers that their current state is still far from optimal, and that there is a meaningful gap your technology can help close. That takes a lot of communication, and it also takes real experimental data.
My role was more about helping the team make those calls than trying to push every direction forward at once.
In this chapter, I was more of a thought partner than the person owning the whole product. I mainly helped in three areas:
Strategy Working with the team to discuss where the real focus should be. Depending on the product advantage and the customer pain point, the emphasis could shift toward IEMS, AI powertrain, or AIoT.
Business model Clarifying how the OEM path and the fleet service path should be split. That also meant looking at related international competitors, how the market was evolving, and where it still made sense for us to push.
Technical feasibility Looking at the feasibility of energy control, smart charging, SOC / SOH, range estimation, and data collection. The goal was to identify which parts were true technical bottlenecks, discuss them clearly, and help solve them where I could.
I was also involved in core IoT-device algorithm work and AI battery-efficiency research. Put simply, I was there to help the team make the technical and product decisions a bit clearer before pushing too many things at once.
The public materials show the product and technical surfaces. Most of my work sat underneath that layer, where the harder questions were about product logic, technical boundaries, and tradeoffs.
Once I got involved, I spent most of my time helping clarify the product and business logic.
vehicle-side vs. cloud-side This includes data collection, efficiency control, battery-health estimation, driving-behavior analysis, and more. As the number of functions grows, the architecture split becomes much more important.
throttle control and efficiency regions I also learned a lot through the design discussions and research around throttle response, motor-efficiency regions, and energy-consumption curves. This was less about shipping one big feature and more about filling in the key logic step by step, while also following the latest research directions.
OEM vs. fleet At the same time, we kept looking at which capabilities made more sense as OEM-integrated components and which were better suited to stay in the fleet AIoT platform.
The full system is currently described as an In-Vehicle Energy Management System. For me, an important part of this chapter was helping connect these threads into a product path that felt easier to move forward with.
IEMS Architecture
The public IEMS materials connect data collection, driver analysis, efficiency control, and the OEM / AIoT sides of the product. One thing I was helping with was making that path easier to explain and easier to move forward with.
AI Powertrain
It is less about drawing a clever curve and more about whether the output curve actually matches the motor's efficiency regions and real usage conditions.
Efficiency Comparison
A table like this is useful mostly because it helps the team see whether a given control strategy is actually helping, instead of just sounding promising.
For me, the more meaningful outcome was whether the direction became clearer and closer to something the market could understand.
During this process, the product gradually moved closer to what the market could actually understand. A strong technical foundation slowly started turning into something that looked more like a market-facing product.
At this stage, a few things are visible:
The work focused on strategy, business model, and technical-feasibility framing.
It also included core IoT algorithm work and AI battery-efficiency research.
I helped the team clarify the OEM and fleet product paths.
Commercial Model
The same technical stack can support different products, but OEM and fleet work really do have different buying, deployment, and development rhythms. Separating them early saves a lot of confusion later.
>OEM: closer to vehicle-side integration, including throttle control, VCU, motor / controller, and battery-management related modules.
>Fleet: closer to an AIoT service layer for SOC / SOH, range estimation, driver-behavior analytics, and live vehicle information.
>The two tracks can share the same core technology, but the packaging and sales motion are quite different.
Advisor Note
❝ If the order is not clear, deep-tech projects can stay busy for a long time without becoming clearer.
In deep-tech work, one of the hardest things is usually turning technical capability into something the market can actually understand and want.
I usually come back to three questions:
If the order of those questions is not clear, teams can work very hard and still feel blurry about the main direction. When the order is right, even a fairly difficult problem starts to become more manageable.
Contact
Helped the team turn a fairly wide set of energy, charging, and IoT / AI ideas into a clearer product direction that was easier to explain to the market.
Related Writing
Anthropic's new article made me more certain that AI agents also need role separation. A lot of team lessons get repeated almost exactly.
Once AI lowers the cost of execution, the scarcer skill becomes planning, judgment, and knowing what should happen first.