In an all-hands meeting shortly after I started a new job as a software engineer, our engineering lead introduced a project we would be building from scratch: a ride-hailing application that would operate in Madagascar.
From a software engineering perspective, the opportunity was exciting. We would be designing, building, and eventually scaling a mobility platform that people could use in their daily lives. My immediate thoughts were about the technologies we would use, the architecture we would design, and the engineering practices we would follow.
It took us the better part of a year, including many working weekends, to release the first version to the public.
As with any software product, once people started using it, we began examining its performance. We analyzed patterns in user activity, the effectiveness of our ride-matching algorithm, pickup waiting times, and other operational metrics. Our objective was relatively straightforward: maximize revenue while maintaining customer satisfaction.
But the data began revealing problems that we hadn't anticipated.
Average pickup waiting times were around 10 minutes, and the number of completed rides seemed to have reached a ceiling despite our efforts to improve the system.
Initially, these looked like problems we could address through better algorithms, improved dispatching, or more efficient software. But the deeper we looked, the more we realized that some of the limitations existed outside our application.
Antananarivo, the capital of Madagascar, had a road-capacity problem, not merely an application problem.
A World Bank analysis estimated that the average trip in Antananarivo covers approximately 9.3 km but takes 46 minutes. For comparison, a mobility survey in metropolitan Porto found that an average trip of 10.6 km took around 22 minutes.
The datasets come from different years and methodologies, so the comparison is indicative rather than exact. Nevertheless, it illustrates the scale of Antananarivo's mobility challenges.
Software can optimize movement over an existing road network. It cannot manufacture road capacity.
This realization gradually changed how I thought about the systems we were building. Transportation wasn't simply a matter of efficiently matching passengers with drivers. It was shaped by the interaction between infrastructure, urban planning, public policy, economics, and the environment.
And our application was operating within that much larger system.
When Optimization Creates Trade-offs
Our platform was continuously generating data about passengers, drivers, ride durations, demand patterns, and user preferences. We collected, cleaned, transformed, and analyzed this data to understand system performance and identify opportunities for improvement.
But beyond operational efficiency, the data also raised questions about the objectives we were trying to achieve.
- Revenue versus accessibility
Optimizing for maximum revenue could concentrate service in neighborhoods with higher demand or greater purchasing power. But what happens to communities where providing service is less profitable?
- Waiting times versus environmental impact
Reducing pickup waiting times might require keeping more vehicles available across the city. While this could improve the passenger experience, it could also increase unnecessary vehicle movement, congestion, and emissions. Could better demand prediction and vehicle allocation reduce waiting times without creating additional environmental costs?
- Business sustainability versus affordability
A ride-hailing service needs to generate enough revenue to remain financially viable. Yet for many people, regularly using such a service may simply be unaffordable. How should a mobility platform balance commercial viability with broader accessibility?
These were not necessarily problems that could be solved by writing better software.
They involved competing objectives, and improving one metric could sometimes come at the expense of another.
As an engineer, I had spent years thinking about how to make systems faster, more scalable, and more reliable. But these experiences introduced another question:
Were we optimizing the right things in the first place?
We Optimized Ride-Hailing. But Were We Optimizing Mobility?
The more I thought about these challenges, the more I began questioning the objectives behind our engineering decisions.
In software engineering, we often define success through measurable outcomes: lower latency, higher throughput, better resource utilization, and greater system reliability.
For a ride-hailing platform, those metrics might include completed rides, revenue, passenger waiting times, and vehicle utilization.
There is nothing inherently wrong with these objectives. They are essential to running a reliable business.
But optimizing a ride-hailing platform is not necessarily the same as optimizing mobility across a city.
A platform might successfully increase completed rides without reducing overall traffic congestion. It might improve average pickup times while leaving some neighborhoods underserved. It might maximize fleet utilization without improving access to transportation for people who need it most.
The distinction becomes particularly important when thinking about the objective function itself.
What we choose to optimize determines what our systems prioritize.
If the objective is to maximize revenue, the system will naturally favor decisions that support revenue generation. If the objective is to minimize waiting times, it will prioritize decisions that reduce waiting times.
But what if we considered a broader set of objectives?
What would an urban mobility system look like if we optimized not just for the fastest individual trip, but also for affordability, accessibility, emissions, resilience, and the overall efficiency of transportation across a city?
And who should decide how those competing objectives are balanced?
These questions made me increasingly interested in the relationship between technology and the larger societal systems in which it operates.
Where Does Artificial Intelligence Fit In?
This is where my interest in artificial intelligence has started to become more specific.
Having worked on production software systems for several years, I am familiar with the engineering challenges involved in collecting data, processing events, designing algorithms, and building applications that support real-world operations.
But I want to explore how we can move beyond using data primarily to monitor what has already happened and toward using it to understand patterns, anticipate future conditions, and support better decisions.
Machine learning, predictive modeling, and optimization techniques offer interesting possibilities.
For example, could demand forecasting help identify transportation needs in underserved areas rather than simply predict where the most profitable rides will originate?
Could intelligent vehicle allocation reduce unnecessary driving while maintaining acceptable waiting times?
Could mobility data help urban planners identify gaps in public transportation and understand where different modes of transportation—buses, shared vehicles, cycling, and walking—could complement one another?
These are not problems that AI can solve independently.
A technically efficient solution may still be economically impractical, environmentally harmful, or unfair to certain communities. Decisions about transportation also involve public policy, infrastructure investment, human behavior, and the needs of people who actually use these systems.
AI can help us analyze patterns, evaluate alternatives, and make predictions. But deciding what constitutes a better outcome requires looking beyond the algorithm.
It requires understanding the people, institutions, and environments affected by those decisions.
What I Want to Explore Next
My experience building a ride-hailing platform introduced me to urban mobility from the perspective of a software engineer.
Now, I want to understand it from a broader perspective.
Over the next few months, I plan to explore how data science, machine learning, and optimization can contribute to more efficient, accessible, and sustainable urban transportation.
I am particularly interested in investigating how mobility demand varies across different parts of a city, whether predictive models can help improve transportation accessibility, and how competing objectives such as service quality, affordability, and environmental impact can be evaluated together.
I also want to understand the limitations of these approaches. A prediction can be statistically accurate without necessarily producing a fair outcome. An optimization algorithm can perform exceptionally well against its objective while overlooking consequences that were never included in that objective.
This brings me back to the question that started taking shape during my experience building mobility software:
How should a city optimize mobility when efficiency, affordability, accessibility, emissions, and economic sustainability can conflict with one another?
I don't have the answer yet.
But I want to investigate what role AI and data-driven decision-making can realistically play in answering it—and, just as importantly, where optimization alone is not enough.