Pluto Mobility Redefines Last-Mile Delivery with Purpose-Built EVs

0
11

In an interview with AutoEV Times, Akshat Bhatia, Co-Founder, Pluto Mobility highlights the structural gaps in conventional two-wheelers used for last-mile delivery. He explains how purpose-built electric vehicles, engineered for high-frequency operations, can significantly improve uptime, payload capacity, and delivery efficiency. By aligning vehicle design with real-world delivery demands, Pluto Mobility aims to reduce costs while enhancing performance, reliability, and scalability for enterprise logistics players.

Read the full interview here:

AET: India’s last-mile delivery ecosystem relies heavily on two-wheelers designed for personal use. What are the key structural limitations of these vehicles when applied to high-frequency delivery operations?

Akshat: Consumer two-wheelers are designed for short urban commutes, not for 12 to 14 hours of continuous running across 100 to 150 kilometres with a heavy payload strapped on. That mismatch surfaces quickly. 

The issues run deep. Suspension isn’t calibrated for sustained payload; the chassis struggles with repeated high-frequency braking under load, and a heavy payload affects handling at every turn and stop. Over the course of a full shift, it results in frequent breakdowns.

The uptime numbers say it plainly. Cargo three-wheelers and trucks operate at around 97% uptime, while delivery two-wheelers are closer to 65%. Fundamentally, these vehicles lack the capacity for sustained load, limiting daily deliveries.

AET: Pluto Mobility is building purpose-built delivery vehicles from the ground up. What core engineering principles differentiate your vehicles from conventional scooters?

Akshat: The first principle is that we did not start from an existing scooter. We started from the delivery use case itself and questioned the form factor from scratch. The delivery duty cycle is highly specific: launch, short cruise, brake, stop, drop, repeated hundreds of times a day. This creates a very different stress pattern compared to commuting, so every engineering decision is anchored to that cycle.

Three priorities guided the design. Payload is integrated into the structure. Chassis durability, built for constant repetition, with reinforcement for continuous braking and loading across full commercial shifts. And a tilting mechanism that gives you two-wheeler manoeuvrability in dense traffic while keeping the vehicle stable under load.

We also kept the vehicle within the two-wheeler legal classification, a deliberate constraint to ensure seamless adoption without requiring a different license.

AET: You mention the potential to enable up to 2× higher delivery throughput. How does vehicle design directly translate into improved operational efficiency and lower cost per delivery?

Akshat: Delivery output depends on 3 things: orders per trip, vehicle life, and distance travelled. We build around these 3 factors.

A conventional two-wheeler safely carries around 50 kg. Our architecture takes that to 90kg+ without compromising stability. Because the load is structurally integrated, riders can carry more volume without the vehicle feeling unstable, which reduces the number of return trips. Engineering the product from the ground up increases the total number of orders delivered over a vehicle’s usable life by 4x. The same rider delivers more orders with fewer disruptions, which changes the cost per delivery.

AET: Pluto operates an owned fleet to run real delivery operations. How does this approach help in faster product iteration and better alignment with enterprise customer needs?

Akshat: The reason we started as delivery partners ourselves was to understand the problem directly. When you are on the road, you experience things that are difficult to capture through research. Downtime, fatigue, handling under load, and small operational frictions become very clear.

Running our own delivery operations is an extension of that approach. Feedback from the field is addressed at the engineering level, not through temporary fixes in operations. If there is an uptime issue, we fix the vehicle. That keeps the system disciplined. It also speeds up iteration. We get real data from actual delivery conditions, not controlled tests. We have been able to iterate quickly because each version is built on direct operational feedback.

For enterprise customers, this means we are not speaking in terms of specifications alone. We are aligned on output, uptime, and cost per delivery, based on real usage.

LEAVE A REPLY

Please enter your comment!
Please enter your name here