With two people, RideBlitz cannot optimize every part of fleet operations. This article explains the tradeoffs we chose, the reasons behind them, and why those limits can help when serving small-to-mid fleet operators instead of enterprise logistics companies.
How Lean Operations Shape Product Choices
For a small team serving a niche, attention is the first limit: maintaining too many optimization problems at once can reduce model quality. Data is the second: without broad deployment, training signals for model improvement are limited. The third is integration scope, since every supported hardware system and data source creates ongoing maintenance.
These limits led us to architectural decisions that may look conservative on a feature list, but create a more focused, consistent system for our target customers.
We concentrated on the two highest-value EV fleet problems: charging schedule optimization and dispatch queue management. We did not take on routing optimization, driver performance scoring, or predictive maintenance beyond battery state monitoring. Customers often ask why we do not add more. A feature we cannot maintain well can cause more harm than its absence. We prefer doing two difficult things exceptionally well over doing eight easier ones adequately.
The Model Structure We Chose
We handle charging and dispatch as one joint optimization problem rather than two steps. This is not the obvious architecture. Most fleet tools keep them separate: a charging scheduler chooses when vehicles charge, while a dispatch system assigns trips to available vehicles. The connection is usually a vehicle state update, not a shared objective.
We combined them because dispatch depends on the charging plan, while charging depends on dispatch intent. A vehicle assigned an important long-distance trip at 08:00 should receive different charging priority than one serving short urban trips all morning. Separate optimization prevents either system from fully accounting for the other's constraints.
Joint optimization makes the model harder to build and explain. One objective spanning both areas needs a richer formulation and more careful tuning than two simpler models. In our early build, we defined which goal wins during conflicts: morning readiness comes before off-peak cost savings. When SOC is a constraint, dispatch response time comes before route efficiency. These priorities are explicit in the model and visible to operators, who can see what the system is optimizing and why.
Why Small Fleet Operators Fit Better
Enterprise fleet tools are designed for scale: hundreds of vehicles, multiple depots, and complex organizations where charging and dispatch belong to separate teams. Their features reflect that, including detailed reporting hierarchies, multi-tenant architecture, compliance tools, and large ERP integrations.
An operator with 15 EVs in Jakarta does not need those layers. The added complexity becomes a burden. They need to know when each vehicle should charge, which vehicle should take the next trip, and when a problem may be approaching. These are not easier versions of enterprise problems, but differently shaped ones. Decisions are finer grained because one poorly timed charging session can affect 8 percent of the fleet.
Our inability to serve every use case fits operators who want a focused tool that needs no dedicated IT team for setup. We can deploy and configure a new fleet in a day. An enterprise platform may need weeks of integration before delivering useful results.
Data Discipline Tradeoffs
Without a broad deployment base, we cannot train on the range of data available to large-scale vendors. We address that limit by stating clearly what the model does and does not know, rather than implying it has more signal than it really does.
When uncertainty is high, the system shows it to the dispatcher instead of issuing a confident recommendation from limited evidence. A vehicle sitting at the depot for 12 hours without a telemetry update will not receive a confident readiness score for a trip. It will be flagged for manual confirmation. That can look like a weakness, but a confidently wrong recommendation costs more than a cautious one requiring human review.
This reflects our broader approach to working with operators. We built a reasoning layer that shows the inputs behind each dispatch recommendation: why the vehicle was selected, its current SOC, last night's charging schedule, and any flagged constraints. Operators can override recommendations, and those overrides provide model feedback. Recommendations that cannot be examined are overridden arbitrarily, reducing the model's ability to learn from real fleet behavior.
What We Have Deferred
Being clear about scope means identifying what we postponed. Multi-depot coordination is a genuine gap. An operator with vehicles at two charging sites in different parts of Jakarta needs cross-depot scheduling, while our current model assumes one depot. That limits the fleet types we can serve today.
Driver behavior modeling is another deferred area. Some EV fleet tools score individual efficiency, braking behavior, and the effect of driving style on range. We left this out of the initial phase because it needs more invasive telematics and raises different governance questions than vehicle-level telemetry. Small-to-mid fleet operators often have close relationships with drivers, and scoring can create friction. We may revisit it, but it is not part of the current build.
These tradeoffs reflect our position as a small team in an early product stage. Some will change as the team grows and gains more deployment experience. Our core approach will remain: focus on the highest-value problems for a defined customer type instead of pursuing broad coverage.
