By Eryk Michael Smith/KHT Staff. Images courtesy of RideFair.

KAOHSIUNG — A truck can follow the fastest route, arrive at the right address, and still spend two hours going nowhere. It might be waiting for its turn to unload; often with the engine running to keep the air conditioning on. Meanwhile, another truck from the same company could be heading across town with space for more cargo.

For Richard Wiltgen, founder of Kaohsiung-based startup RideFair, those are connected problems. Finding a better route for each vehicle is only part of the answer. The bigger question is whether the vehicles are doing the right jobs in the first place.

“We don’t look at vehicles, we look at fleets,” he said.

RideFair is developing software to examine delivery and passenger transport operations as a whole, looking for opportunities to combine loads, reduce waiting time and avoid unnecessary journeys. Its intended users include smaller delivery companies, shuttle operators, rural transport providers and fleets taking patients to nonemergency appointments.

The company operates from Startup Terrace Kaohsiung (亞灣新創園), a startup hub established by the Ministry of Economic Affairs’ Small and Medium Enterprise and Startup Administration. The government-backed initiative supports technology startups through workspace, business connections and access to international networks.

From that base, Richard Wiltgen – who asked to be referred to by his first name – is pursuing a business opportunity and a much larger idea: first help operators make better use of their vehicles, then work toward a system in which those vehicles exchange information and coordinate their movements.

For now, RideFair is in development and validation. The task ahead is to demonstrate that opportunities identified in historical data can become reliable improvements on the road.

The many fleets vs. the mega fleets  

Richard’s interest began with a market he believed was being overlooked.

Large logistics companies have the scale to invest in sophisticated systems. Smaller operators still have to decide which driver goes where, what each vehicle carries, and how to respond when the day stops going according to plan.

Their tools, he found during his research, could be considerably less sophisticated: older software, navigation apps or a whiteboard.

He rejects the explanation that smaller businesses simply resist change.

When he asked why operators were working that way, he said people outside those businesses repeatedly described them as “traditional.” His own conclusion was that the available products could be too expensive, too cumbersome, or poorly suited to their needs.

“All these small and medium companies know that the software companies don’t care about them,” he said.

That is Richard’s assessment of the market, and the premise on which he is building the business. Rather than compete for the largest international delivery networks, he wants to make fleet coordination useful and affordable for companies operating on a smaller scale.

The vehicles do not all have to carry boxes. A van taking older people to medical appointments faces some of the same scheduling questions as a delivery truck: where it needs to go, when it needs to arrive, how much capacity it has and what else it could do along the way.

When a navigation app cannot help an operator

Asked why a business would need something beyond Google Maps; Richard was quick to praise the navigation service. RideFair, he said, uses it in parts of its own work.

But there’s a difference between planning a journey and organizing a fleet.

A driver can ask a navigation app how to get from one address to another. The fleet operator has a different set of questions. Should that driver make the trip? Could another vehicle handle it? Would changing the order of several deliveries reduce the total work?

Richard illustrated the issue with two hypothetical 10-seat vans. One carries seven people; the other carries one. “And do you really even need both vans?” he asked.

The same reasoning applies to cargo. A truck that looks busy on a dispatch sheet may be traveling with only a small portion of its capacity filled. Several individually reasonable assignments may add up to an inefficient day.

“The things that matter are the idle time, the things that matter are crisscrossing, the things that matter are capacity,” he said.

But what if passengers need to travel at significantly different times? Or what if people aren’t willing to go on a “logical-to-the-software” detour? Richard says those are the conflicts he wants the software to examine – and solve – across an operator’s schedule.

Useful answers can be unexpected ones

One of Richard’s examples involves a chemical manufacturer in Kaohsiung that handles deliveries with its own five-vehicle fleet.

The routes initially appeared straightforward: leave the plant, visit a sequence of customers and return. Wiltgen said he did not expect to find much room for improvement.

The first analysis was disappointing, he said, falling short of his internal savings target. But it drew his attention to something less obvious than the route itself: vehicles spending long periods waiting.

According to Richard, the records suggested that the company could potentially handle work assigned to three trucks with two, without reducing delivery quality.

A truck waiting at a delivery point may have other work it could complete. If its schedule and the other vehicles’ schedules were coordinated, it might make another delivery and return nearer the time it was needed, or the job might be reassigned.

The opportunity would come from changing the allocation and sequence of work, rather than shaving a few minutes off the drive.

Richard said he wants the analysis to expose weak results as readily as promising ones.

“I build my software to be mean to me,” he said. “I don’t want any surprises anywhere down the road.”

Costs go beyond the fuel tank

Fuel savings are an obvious selling point for transport software, but Richard is also interested in what happens to the vehicles themselves.

Driving means maintenance and wear. An operator that needs fewer vehicles in daily service may be able to distribute work differently across its fleet and reduce pressure to replace equipment.

Richard said RideFair is examining measures including fuel use, carbon emissions, vehicle capacity, driver time, maintenance and replacement costs.

The potential benefit depends on the operation. A fleet with tightly organized deliveries may have little scope to shorten its routes but more scope to reduce waiting. Another may have substantial overlap between vehicles’ journeys.

He argues that operators need to see the whole picture before deciding where to spend money.

Buying another vehicle is one possible response to a busy schedule. Understanding whether existing vehicles could handle that schedule differently is another.

Why “fair” is in the name

Richard’s background includes work on video game projects, and his explanation of RideFair’s name begins with a familiar irritation for players: buying a game, then discovering that desirable features require additional payments.

“One thing that I hate is when you buy a video game, and you’re playing it. And in order to get access to all the very coolest stuff, you have to pay more money,” he said.

That frustration informed his thinking about the cost of fleet software, particularly products tied to dedicated equipment and recurring hardware charges.

His proposed approach allows operators to use phones rather than requiring them to lease proprietary hardware. A company that prefers a separate device could buy one, he said, without having to purchase it through RideFair.

The software itself would carry a monthly subscription. Wiltgen said pricing would depend on vehicle size and monthly distance traveled.

The aim is to lower the equipment barrier to trying the service. Whether the overall price makes sense for an operator will depend on what the software can demonstrably save.

Replay the day before changing it

RideFair’s starting point is historical GPS and dispatch data: records showing where vehicles traveled and what they were assigned to do.

Richard describes a replay process that reconstructs past operations and examines alternative arrangements. Rather than asking an operator to immediately reorganize its fleet, the approach begins by testing changes against records of work already performed.

The company’s website describes its current status as “pre-deployment validation.” It lists a first public-data demonstration for November 19 at Meet Taipei, ahead of a pilot in early 2027.

Rural vans before city buses

Passenger transport is part of Richard’s thinking, but he’s currently more interested in smaller van services than a city’s conventional bus network.

He said he had already contacted operators serving rural areas, seeing opportunities to reduce waiting times, driver time, fuel use, and vehicle wear.

Those services fit his interest in fleets with recurring transport needs, but that may lack the resources of a major logistics business.

Redesigning how city buses operate is a more ambitious prospect that would require some brave moves by transport authorities, and a shift in deeply ingrained public perceptions.

Richard questions whether fixed bus routes should remain the organizing principle for every service. His preferred alternative is what he calls a “smart swarm”: vehicles adjusting to demand while accounting for the destinations of passengers already aboard.

Instead of treating each bus as permanently attached to a numbered route, software would examine how several buses could collectively serve the people who need them.

The idea raises practical questions. A change that helps a waiting passenger could delay someone already traveling. Riders would need understandable information and confidence that the service would get them where they were going.

Richard argues that such proposals should first be tested with historical data. He also believes a meaningful experiment would require enough vehicles to allow assignments to shift between them.

He is not currently proposing to reorganize Kaohsiung’s city bus network. Conventional bus services are outside RideFair’s immediate focus, he said.

An idea shaped in Luxembourg

Richard traces some of his interest in flexible public transport to Luxembourg, where he previously had a company.

He spoke warmly of its public transport system, but said it also prompted him to wonder whether even a well-supported network could operate differently.

“If you’re going to do swarm thinking, this is the perfect place to do it,” he recalled thinking.

That question has carried into his work in Kaohsiung: what could change if vehicles were planned as a group capable of adjusting together?

For now, he sees waste collection as one possible route toward demonstrating the value of that approach. Collection fleets perform repeated journeys, providing records against which alternative arrangements can be examined.

His hope is that evidence from one type of municipal operation could eventually open a conversation about another.

Moving toward all vehicles “talking to each other”

RideFair has not yet built a functioning citywide network, and the company needs to demonstrate that its recommendations are reliable and that operators can integrate them into daily work.

Before vehicles can make collective decisions across a city, RideFair needs to show an operator something useful about tomorrow’s schedule: which truck should leave, what it should carry, and whether another truck needs to leave at all.

Richard Wiltgen’s longer-term vision, however, goes beyond a central computer issuing better instructions and into what’s still thought of by many as something from a sci-fi movie.

He wants vehicles to exchange information with one another. A vehicle encountering a slowdown could contribute information that helps others adjust. Collectively, the fleet would develop a fuller picture than any one driver could have.

Comparing the vehicles to brain cells contributing to collective decisions, another ambition is to preserve some coordination when internet access fails. Vehicles within range could exchange information locally, he suggested, gradually passing knowledge through the fleet as they encounter one another.

“Eventually,” he said, “we’re going to live in a world where every single vehicle talks to every other vehicle.”