A bike or scooter rental app has a narrow job. It has to put a rider on a working vehicle, keep a trustworthy GPS trail, enforce parking, and close the fare when the lock shuts.
Ride-hailing clones and citywide MaaS planners can wait. You're not building that yet.
If you run a fleet, you're really shipping three products: the rider app, the staff console, and the vehicle layer that talks to locks and GPS. Miss the third one and the first two become fiction.
So which layer do you finish first?
That's the budget question.
What the product has to cover
You need four layers that stay honest with each other. Drop one and the rest start lying.
| Layer | Job | What breaks if it's weak |
|---|---|---|
| Rider app | Find, reserve, unlock, pay, end | Abandoned trips and chargebacks |
| Operator console | Status, rebalancing, tickets | Dead vehicles sitting all day |
| Vehicle / IoT | Lock, GPS, battery, alarms | Ghost bikes, theft, bad ETAs |
| City rules | Geofences, hours, caps, reports | Permit trouble and impounds |
A single-mode bike or scooter share is simpler than a multi-modal planner. You lose bus-plus-scooter itineraries. You keep a system a small team can actually run.
The ride, from unlock to lock
The rider loop is find, hold payment, unlock, ride, park, pay. That's it.
They scan a QR code or tap Bluetooth. The lock opens. GPS keeps a trail. At the end you check the geofence or ask for a photo, then you capture the fare and free the vehicle.
Staff live on a different screen. They need low-battery alerts, missing GPS pings, damage tickets, and a way to idle a vehicle before a city inspector shows up.
Staff should see that without digging.
Thing is, the phone and the lock often disagree. If the lock shut at 4:10 and the rider's phone only closed the session at 4:16, credit the extra minutes without a support ticket.
Hardware, maps, and geofences
QR codes are the cheap unlock. Bluetooth helps when cellular is weak. An LTE modem on the vehicle keeps pings coming if the phone dies.
You will fight parking zones. Cities draw piles of corrals, and a phone can't watch every fence at once, so the server should push only nearby zones as the rider moves.
GPS will lie next to glass towers. Give a small grace radius and an appeal path, or you'll spend nights on parking disputes.
Turns out the map SDK is the easy buy. Lock firmware and local parking rules are what blow the calendar.
React Native and Node.js show up in a lot of lean quotes because one mobile codebase plus a simple API can absorb the evening unlock spike, which is fine when your locks already speak a documented protocol, but if the hardware vendor still hasn't given you a reliable unlock command then you don't really have an app project, you have a hardware delay wearing a map.
A build sequence that doesn't lie to you
Finish the permit and the lock before you polish onboarding copy.
- Read the city permit: vehicle cap, hours, parking rules, and any data you must share.
- Get one test lock talking before anyone draws more screens.
- Build the rider loop with real GPS, not a fake pin in the office.
- Authorize payment at the start, capture at the end, and refund failed unlocks.
- Ship an operator view: vehicle list, status, manual lock, impound flag.
- Load real corrals and walk them. Office geofences lie.
- Soft-launch a small fleet. Watch failed unlocks for a week, then add vehicles.
Skip the hardware proof and the pretty UI is a slideshow.
What this usually costs
Quotes move with labor rates and city count. Treat brochure prices as fiction until a lock is on the bench.
| Scope | What you usually get | Ballpark |
|---|---|---|
| Lean software MVP | Cross-platform rider app, basic admin, card payments, QR unlock, map polling | Often quoted around $25,000 to $45,000 over three to four months |
| Mid | Better telemetry, geofences, tickets, iOS and Android polish | Higher, still mostly software |
| Multi-city or custom IoT | Firmware work, offline unlock, franchise controls, anti-tamper | Frequently $120,000 and up |
Those figures assume you are buying known locks, not inventing them. to be honest, the invoice follows the hardware, not the design file.
How operators actually get paid
Per-minute pricing is the default. Per-ride pricing is the default too, in a way, because both are easy to explain at the dock. Monthly passes help the person who unlocks twice a day.
A pre-authorization at the start, then a capture at the end, cuts some fare-hopping. It won't stop a stolen scooter.
Campus or employer passes billed in a batch can work. So can a timed hold on one bike that expires if the rider never shows. Damage charges only stick if you require an end-of-ride photo.
Don't put ads on the navigation view. The rider is rolling. A failed unlock costs more than a banner.
Location data, privacy, and city permits
Precise GPS is how you bill. It's also how you get in trouble.
The FTC InMarket order barred that firm from selling precise consumer location data. The Commission said each violation of such an order may bring a civil penalty of up to $51,744. Don't turn your riders' trails into an ad product.
Collect the trip. Stop there. Say that in the permission prompt.
U.S. rules are local. One city caps fleet size and overnight hours. The next wants designated parking or extra reports. European cities add their own age, ID, and parking terms. Don't paste another market's policy into yours.
If a city wants raw traces, ask whether they aggregate paths. A ride path can identify a person even without a name.
Open feeds if you need other apps to list your bikes
Want third-party maps to show your vehicles? Publish a GBFS feed. MobilityData now maintains that spec, used by more than 730 systems in over 40 countries, and OpenTripPlanner can consume it if you add shared-bike routing later.
Get one lock talking on the bench, one real corral loaded as a geofence, and a payment sandbox that can reverse a fare. If those three behave, hire for the rest. If they don't, extra screens won't help.