Design a scooter sharing app

Most candidates treat this as a consumer UX exercise and deliver a feature list: map with pins, QR unlock, in-app payment, helmet reminder. That is not a product design answer. It is a description of the status quo as of 2018. The real question is harder: why do scooter-sharing businesses struggle to make money, and what design choices change that? If you cannot answer that, you cannot choose features on defensible grounds.

Start with a clarifying question that forces a strategic choice

Ask: “Are we designing from scratch for a new city concession, or improving an existing operator’s app for a specific market?” This matters because in 2026, cities no longer issue open permits. They award concession contracts to one or two operators per city, require equity-zone deployment in underserved neighborhoods, and mandate GBFS (General Bikeshare Feed Specification) data-sharing. You are designing inside a regulated marketplace, not a free launch.

A focused setup worth stating out loud: an existing operator entering a new mid-sized US city under a concession contract. The city has decent transit density but a persistent first/last-mile gap. That gap is the product’s only real job.

Pick the segment that determines viability

Do not pick “urban commuters” as your segment. Pick precisely: a 28-to-40-year-old professional who takes the subway for the main leg of the commute but has a 0.6-to-1.0-mile gap between the station exit and their workplace. They are willing to pay a weekly or monthly subscription if they can depend on the scooter being there every morning. This is the segment where LTV lives: committed subscribers generate $40-60/month versus $5-8 for a tourist one-timer.

Note the demographic constraint as a product opportunity: 75% of micro-mobility riders are men. Closing that gap is not just an equity box to check; it is a growth surface the business has not captured. That framing will distinguish you at a senior level.

The three real pain points, in priority order

1. Availability anxiety destroys the habit loop. If a commuter walks to a scooter spot and finds nothing twice in a week, they stop checking the app. The business loses a high-LTV user permanently. This is the single most important problem to solve, and no existing feature addresses it proactively.

2. Battery anxiety mid-trip. The app shows a battery percentage on a map thumbnail, but the user has no clear signal whether the scooter will reach their destination. Tier Mobility pioneered swappable batteries across its European fleet. The app must surface a battery-to-destination indicator before the user commits to unlocking, not after they are already riding.

3. Parking uncertainty at the destination. Will I get a fine? Will I be blocked from ending the ride? This anxiety stays live for the entire trip. If users cannot confirm they are in a legal drop zone before letting go of the handlebars, the ride ends on a bad note even when everything else worked.

Feature prioritization

Build first: reserve for commute. Let users pre-book a scooter 15 minutes before their usual departure time, using predicted availability from historical demand patterns. This directly kills availability anxiety and makes the habit loop sticky. It also gives ops a demand signal the night before, so rebalancing algorithms run while scooters are idle, not after the commuter is already disappointed.

Build second: battery-to-destination indicator. Before unlock, show “this scooter reaches [destination] with X% to spare,” drawn from GPS route distance and scooter telemetry. Do not show a raw percentage. Show a route-aware verdict. This is the anxiety-to-confidence conversion at the moment that matters.

Build third: guaranteed parking at transit nodes. Pre-negotiate designated drop zones with the city at train and bus stations. Surface the nearest confirmed zone on the ride screen 90 seconds before arrival. Send a push notification confirming the return was accepted. This closes the anxiety loop and eliminates the top support-ticket category.

Defer: tourist discovery features, gamification, social sharing, and multimodal trip planning. They add product surface area without touching the unit economics problem.

The viability constraint you must name explicitly

Bird’s original unit economics were punishing: approximately $2.43 revenue per mile against approximately $2.55 in costs per mile. Early scooters lasted about three months in the field but needed four months of rides to break even. Modern hardware achieves two-to-eight-year lifespans, which changes the math substantially. But 60% of per-ride cost still goes to rebalancing and charging labor. The product design implication: features that drive organic redistribution have higher ROI than features that require more operations headcount.

A concrete example: offer 3 free minutes to any user who rides a scooter from a high-density zone to a designated low-density zone on the city’s equity map. This simultaneously reduces labor cost, meets the city’s equity-zone deployment requirement, and generates goodwill with the concession authority. One feature doing three jobs.

The global e-scooter sharing market was $1.81B in 2025 and is projected to reach $7.08B by 2033 at 18.6% CAGR. Lime has posted four consecutive years of 30%+ revenue growth and is now profitable. The survival model is predictive rebalancing, not supply flooding. That is the design argument in one sentence.

Metrics

The north star is not rides per day. It is weekly active commuter rides: specifically rides taken Monday through Friday between 6-9 AM and 4-7 PM. This metric correlates with subscriber conversion, which is where LTV lives. Raw ride counts can grow while the business degrades if growth comes from tourists and one-timers.

Metric	What it signals
Weekly active commuter rides (peak hours)	Habit formation and subscriber conversion
Rides/scooter/day by zone	Fleet utilization and rebalancing effectiveness
Reserve-to-ride conversion rate	Whether predictive availability drives real behavior
Battery-anxiety abandons (unlock tapped, then cancelled)	Product gap on battery transparency
Parking fine rate per 100 rides	Trust, compliance, and city relationship health

The 2026 reframe

In 2026, feasibility is effectively free. The hardware works, the maps API exists, the payments rails are standard. The real product challenge is: how do you make a scooter available, reliable, and predictable enough that a commuter builds a daily habit around it? Habit is the only path to the LTV that makes the unit economics work. That means the PM’s job is anticipating when and where someone needs a scooter before they open the app, not just showing them a map when they do. Proactive availability, route-aware battery state, and guaranteed parking at transit nodes are 2026-grade lovable. A map with pins is 2018.

The paired estimation question, estimate e-scooter rides in SF, tests the same underlying fluency with micro-mobility economics. Study them together.