Why Mobility Startups Cannot Scale Like SaaS

Why Mobility Startups Cannot Scale Like SaaS

Mobility demand can scale through software. Mobility service does not become software.

Each trip still requires a person or asset in the right place, in a usable state, at the promised time. Insurance, payment processing, maintenance, support, local operations, recovery, and the consequence of a missed journey remain connected to real activity.

That does not make mobility a bad technology market. It makes a pure software growth model incomplete.

The interface and the service scale differently

A software product can often serve another customer by replicating computation. The marginal cost may be low, and the product can reach a new geography without placing a physical asset or operator there.

A mobility platform can distribute its app nationally while the service remains local. The car must exist where the customer expects it. It must be charged or fueled, maintained, clean, accessible, insured through the appropriate arrangement, and recoverable when it fails. A ride platform needs a driver or autonomous system in the market. A shared-bike network needs repositioning, repairs, and charging. A peer-to-peer marketplace needs hosts, protection, claims, support, and roadside assistance.

Software can remove work. Digital keys can eliminate a scheduled exchange. Telemetry can expose some failures before pickup. Routing can improve asset use. Automation can guide common exceptions.

The remaining physical obligations do not disappear because the customer encounters them through a polished screen.

flowchart LR
    A["More digital demand"] --> B["More trips or booked days"]
    B --> C["More payment and network activity"]
    B --> D["More insurance exposure"]
    B --> E["More support and exceptions"]
    B --> F["More asset use and maintenance"]
    C --> G["Operating margin"]
    D --> G
    E --> G
    F --> G
    H["Automation and better operations"] --> C
    H --> D
    H --> E
    H --> F

Technology can improve each operating path. It does not make trip-linked activity stop existing.

Rei Vardi learned the distinction while trying to raise

Eon founder Rei Vardi initially believed he needed venture capital to build a national platform. He describes pitching for two years and living in his father's minivan in San Francisco while meeting investors.

He also began to understand the hesitation. Investors had already seen mobility companies grow quickly and struggle with the physical work beneath the interface.

Rei's formulation was direct: software investors are accustomed to businesses in which serving the next large group of users does not require a proportional increase in local work. Mobility retains people, maintenance, insurance, and liability. If the company expands before it knows those costs and failure modes, capital can make the problem larger.

That is a founder's interpretation, not a complete history of the mobility sector. The unnamed companies and valuations in his account are not independently verified in this package.

The current filings of larger mobility businesses support the narrower cost argument.

Public filings show costs moving with trips and miles

Uber's 2025 Form 10-K says Mobility Adjusted EBITDA increased with bookings, while growth was partly offset by a $1.6 billion increase in driver payments and incentives, an $851 million increase in insurance expense, a $224 million increase in network costs, and a $164 million increase in credit-card processing costs. Uber tied the insurance increase primarily to a higher rate per mile and more miles driven.

Lyft's 2025 Form 10-K describes insurance, payment processing, certain driver costs, local operations, user support, fleet support, vehicle lease expense, maintenance, repositioning, cleaning, and safety checks within its cost structure. Lyft reported that 2025 insurance costs increased by $337.8 million because of higher ride volume and higher cost per mile. It also reported higher driver-onboarding, rider, driver, and car-rental fleet-support costs.

Turo's May 2024 amended registration statement describes a different model. Hosts provide privately owned vehicles. Turo's protection-program costs still included physical vehicle damage, liability insurance premiums, loss reserves, claims processing, and personnel. Its operations and support costs included customer support and roadside assistance, and the filing expected those costs to increase as booked days grew.

These companies differ from one another and from Eon. The filings do not establish a universal margin, failure rate, or financing outcome. They show that software-mediated mobility retains costs whose drivers include trips, miles, booked days, claims, vehicles, and exceptions.

Reliability is part of the customer's larger plan

A mobility failure can cost more than the transaction.

A missing vehicle can make a family miss a flight, a worker miss a shift, a founder miss an investor meeting, or a group lose an event planned months earlier. The customer may have paid a modest amount for the ride or rental and built an expensive chain of commitments around it.

Rei emphasized this asymmetry in E116. An hour in a sauna is not the same hour as an hour spent waiting for a car while an important meeting begins elsewhere.

This changes the economics of recovery. The operator is not merely refunding an isolated product. It is trying to contain the effect on the rest of the journey. Replacement supply, airport access, roadside help, customer communication, and local decision authority all become part of the value proposition.

Growth that adds bookings without recovery capacity can increase the number of customers who discover that the interface promised more geographic or operational coverage than the system could deliver.

Marketplace language can hide who performs the work

Asset-light does not mean operation-free.

A platform may not own the car, employ the driver, perform the cleaning, carry every insurance layer, or run the repair. Those responsibilities may belong to owners, contractors, insurers, service partners, or participants.

Moving the cost outside the company's payroll can change the financial model. It does not eliminate the customer dependency.

The product still needs to know whether the asset is ready, whether the operator is eligible, whether support can resolve the failure, and whether the incentives make each party perform the work the marketplace requires.

This is why gross margin alone can be a weak description of the customer system. A company can show attractive platform economics while owners absorb maintenance, participants absorb waiting, or local contractors absorb volatile demand. The business may still be viable. The work needs to be identified honestly.

Hypergrowth is dangerous when the failure modes are still unknown

The familiar venture sequence is to acquire users rapidly, establish the market, and improve economics after scale.

That sequence works best when the company understands what it is replicating. A product can have imperfect economics and a well-defined mechanism for improvement. A mobility company that is still discovering how identity, availability, safety, maintenance, insurance, local service, and recovery interact may be replicating an unstable experiment.

More volume can help the company learn. It can also make the evidence noisy. Promotional spending, manual support, founder intervention, and unpriced risk can keep the experience working long enough for the organization to mistake effort for a repeatable system.

Rei's first Tesla made this visible at the smallest scale. The booking page created demand. Rei personally supplied the key exchange, customer support, damage response, and coordination. The business looked digital because the hidden operating layer was one exhausted founder.

The same concealment can exist at larger scale through contractors, incentives, insurance reserves, or unusually high support effort.

Bootstrapping is not the universal answer

Eon's story can be misread as a simple lesson to reject venture capital.

Bootstrapping can force a company to learn economics earlier. It can also leave a team underfunded for safety, security, insurance, maintenance, compliance, or the technology needed to remove dangerous manual work.

Venture funding can finance infrastructure before revenue catches up. It can also create a growth expectation that does not fit the pace at which a physical system can be validated.

The correct capital model depends on what must be learned, how expensive a failure is, whether the next market requires local assets, how quickly the operating system becomes repeatable, and whether each dollar of growth buys durable capability or temporary volume.

The financing question follows the operating model. It does not replace it.

A better sequence begins with bounded reliability

Start with a market where the company can observe the whole transaction. Know what the customer expects, which party performs each task, what a normal trip costs, how often exceptions occur, and what each recovery consumes.

Separate the work technology genuinely removes from work it merely routes. Measure the completed experience, not just the booking.

The most useful measures will vary, but the operating questions are stable. Was the promised asset or operator ready? Did the customer begin on time? How many transactions required manual intervention? How long did recovery take? What did the exception cost? Which party absorbed it? Did the same failure recur?

Expand when the new market can carry the same readiness checks, support authority, maintenance, replacement, insurance, and recovery. A national app with local improvisation is not yet a national operating system.

The strongest counterargument

Software has already transformed mobility. Matching, routing, pricing, mapping, payments, vehicle telemetry, digital keys, driver communication, and support automation can improve asset use and reduce cost.

Scale can also create density. More riders and drivers can reduce wait times. More vehicles can improve replacement options. More transaction data can sharpen fraud, safety, demand, and maintenance decisions. Larger purchasing power can improve insurance or supplier economics.

All of that is real. It does not contradict the thesis.

The claim is not that mobility lacks software economics. It is that the customer outcome remains coupled to physical capacity, local execution, and trip-linked exposure. The winning company may use software to make that system far more efficient. It still has to scale the system.

What this changes

Founders should stop asking whether the company is a technology company as if the label decides the growth model.

Ask what must be true for the next transaction to succeed. Name every physical dependency, every risk transfer, every party performing hidden work, and every exception the customer cannot solve alone. Then decide how technology changes the amount, timing, ownership, or visibility of that work.

Mobility can be highly automated, national, and profitable. It cannot become reliable by treating the physical world as an implementation detail.

Episode 117 offers a related case in which a digital control system still has to survive real machinery. Episode 119 develops the real-use testing method. Episode 100 adds a founder operating-system perspective, while Episode 25 connects mobility design to operational boundaries and liability.

Sources and further reading

The founder argument comes from Rei Vardi's interview in [[E116 Full Transcript]]. Current Eon context comes from the official site and privacy policy. The external operating evidence comes from Uber's 2025 Form 10-K, Lyft's 2025 Form 10-K, and Turo's May 2024 amended registration statement.

AI assisted with organization, source comparison, and editorial review. Dalton Anderson's transcript and the linked primary filings control the factual claims.