Micromobility Software Development Company

Custom software for e-scooter operators, bike-share companies, micro-transit startups, and campus fleet managers whose operational complexity, city compliance requirements, or rider experience expectations have outgrown generic white-label platforms. When your rebalancing logic, IoT lock integrations, dynamic pricing rules, or multi-zone geofencing setup can't be expressed in the config layer of an off-the-shelf tool, we build the system around how your fleet actually runs.

  • IoT fleet control with real-time GPS, lock and unlock commands, battery telemetry, and fallback handling for low-connectivity zones

  • Rider-facing iOS and Android apps with account management, ride history, in-app payments via Stripe, and city-compliant end-of-ride photo capture

  • Fleet rebalancing systems with demand forecasting, zone utilization scoring, and task routing for field teams

  • Dynamic pricing engines that adjust per-minute rates by zone, time of day, battery level, and local demand

Recognition

Sound familiar?

  • Rebalancing crews working from guesswork because your fleet dashboard shows vehicle location but not demand forecasts or zone-level utilization rates?

  • Locked into a white-label platform that handles 80% of your operations but forces workarounds for the pricing model, maintenance workflows, or city permit data your contract actually requires?

  • IoT lock commands timing out in low-signal areas and your ops team spending hours manually triaging stranded vehicles with no fallback protocol in the software?

The short answer

RaftLabs builds custom micromobility software for e-scooter operators, bike-share companies, micro-transit startups, and corporate fleet managers. Our micromobility software development covers IoT lock management, rider-facing mobile apps, fleet rebalancing systems, dynamic pricing engines, maintenance scheduling, and geofencing, delivered in 12 to 18 weeks at a fixed, agreed cost.

What is micromobility software?

Micromobility software is the operational and customer-facing technology that runs shared e-scooter, bike-share, moped, and micro-transit services. It connects IoT-enabled vehicles to rider apps, fleet management dashboards, maintenance scheduling tools, dynamic pricing engines, and city-permit compliance systems, turning a physical fleet into a managed, data-driven transport service.

01 Diagnosis

Problems we solve for micromobility operators

  1. 01
    Problem

    Your rebalancing crew works from guesswork, not data

    Solution

    Vehicles cluster in high-demand zones after morning rush and sit untouched in residential areas until someone drives out to move them. Without zone-level demand forecasting and utilization scoring in the ops dashboard, field teams plan their day on intuition. The result is a rebalancing cost that often exceeds the ride revenue those zones generate.According to McKinsey, fleet-sizing and rebalancing algorithms have reduced rebalancing time by 12 to 28% in tested shared micromobility systems, a direct saving on the labour and fuel costs that erode per-vehicle margin. A rebalancing system with live zone utilization data, demand forecasting, and task routing for field staff cuts that labour cost while keeping vehicles where riders actually want them.

  2. 02
    Problem

    IoT lock failures strand vehicles and your ops team

    Solution

    Lock and unlock commands drop in low-signal urban canyons, basements, and campus dead zones. When the software has no fallback protocol, the result is a stranded vehicle, a refund request, and a field tech dispatched for what should have been a software-handled retry. Every stranded vehicle is a lost ride and a deteriorating rider rating. If it happens during a city audit, it is a permit compliance risk too.A properly built IoT integration handles command retry logic, queued unlock requests, and offline-mode grace periods at the firmware-software boundary. Connectivity telemetry for each vehicle surfaces in the ops dashboard so your team sees the last successful heartbeat, the SIM state, and the error log before dispatching anyone to the street.

  3. 03
    Problem

    Dynamic pricing is a spreadsheet exercise, not a live system

    Solution

    Pricing set once a month in a config file doesn't respond to a stadium event that triples demand in one zone, a rainy Tuesday that kills ridership across the whole fleet, or a low-battery cluster that costs more to retrieve than the remaining ride revenue justifies. Static pricing leaves money uncaptured at peak demand and fails to move low-utilization vehicles to break-even.A dynamic pricing engine adjusts per-minute and unlock rates by zone, time of day, battery state, and real-time demand signals. All adjustments stay within the fare bands your city permit allows. Operators who run dynamic pricing typically see a 15 to 25% improvement in revenue per vehicle per day compared to flat-rate structures, without increasing rider churn.

  4. 04
    Problem

    Maintenance is reactive because the software doesn't surface failure signals early

    Solution

    A scooter with a battery degrading below 60% capacity gets reported by a rider with a short-trip complaint, not by a maintenance alert. By the time the complaint arrives, the vehicle has been on the street for three days below safe performance thresholds. Reactive maintenance means higher repair costs, more downtime per vehicle, and a rider experience that erodes retention.Predictive maintenance scheduling uses battery telemetry, trip count thresholds, motor temperature logs, and reported fault codes from the IoT layer to flag vehicles before they fail in service. Field teams get a daily maintenance queue with route-optimized task ordering, replacing the ad-hoc repair cycle with a scheduled one that keeps average vehicle uptime above 90%.

02 What we ship

Micromobility software we build

  1. IoT fleet control and lock management

    We integrate with IoT hardware vendors including Segway IoT, Omni, Comodule, and Teltonika using MQTT, REST, and vendor-specific SDKs. Lock and unlock commands, GPS polling, battery state telemetry, motor diagnostics, and over-the-air firmware update triggers are all surfaced through a unified fleet control API that your ops dashboard and field app consume.

    Command retry logic, offline queue handling, and connectivity fallback protocols are built into the integration layer, so a dropped cellular connection in a tunnel doesn't mean a stranded vehicle. Each vehicle's last heartbeat, SIM registration state, and active error codes are visible in the dashboard before anyone is dispatched to the street.

    Built for e-scooter operators managing mixed IoT hardware fleets, campus mobility programmes with controlled network environments, and operators who need a hardware-agnostic control layer as they expand to new vehicle types.

  2. Rider iOS and Android apps

    The rider app covers the full trip lifecycle: account creation with identity verification, vehicle discovery on a live map, QR and NFC unlock, in-ride telemetry display, end-of-ride photo capture for parking compliance, and payment via Stripe or Adyen with support for prepaid wallets, ride passes, and corporate billing accounts.

    Push notifications handle ride reminders, low-battery alerts, and zone-exit warnings before a geofencing penalty triggers. Accessibility features, including screen-reader-compatible ride controls and large-tap unlock targets, meet ADA and WCAG 2.1 AA standards for operators serving university or municipal contracts that require them.

    Built for shared e-scooter and bike-share operators launching or rebuilding their consumer app, corporate fleet programmes with employee accounts and billing integration, and operators whose current rider app has a completion rate below 85% at the unlock step.

  3. Fleet rebalancing and operations dashboard

    The operations dashboard gives fleet managers a live map with zone utilization overlays, vehicle cluster heat maps, battery-level filters, and demand forecasts by hour and zone. Rebalancing task lists are generated automatically from utilization scoring: which zones are over-stocked, which are depleted, and what the minimum move count is to reach target distribution.

    Field teams get a companion mobile app with their assigned task queue, turn-by-turn navigation to each vehicle, and checklist-guided handoffs for battery swaps, physical inspections, and parking corrections. Task completion rates and field team productivity metrics feed back into the ops dashboard for shift planning.

    Built for operators with fleets above 200 vehicles where manual rebalancing coordination creates margin pressure, and for operators adding a second city market who need structured task management rather than team group chats.

  4. Dynamic pricing engine

    The pricing engine adjusts unlock fees and per-minute rates across zones and time windows without a developer touching config files. Rules combine demand signals from the live fleet (vehicle density per zone, active ride count, historical ridership by hour) with external triggers like local event calendars, weather API data from Tomorrow.io, and battery-level cost thresholds.

    Pricing boundaries defined in the city permit are enforced at the rule level so no dynamic adjustment can breach the rate ceiling or floor set in your operating licence. Operators can A/B test pricing variants across zones and review revenue-per-vehicle impact in the analytics module before rolling changes to the full fleet.

    Built for operators at profitability inflection points who need pricing to respond to demand rather than averaging across it, and for operators entering new markets where city contracts include variable rate allowances.

  5. Maintenance scheduling and vehicle health

    Vehicle health scoring runs on telemetry from the IoT layer: battery cycle count and capacity degradation, motor fault codes, trip distance since last service, and rider-reported issues from in-app feedback. When a vehicle crosses a threshold (500 trips since last brake check, battery below 75% rated capacity, three rider complaints in seven days), it moves into the maintenance queue automatically.

    The maintenance queue is served to mechanics as a prioritised daily list with fault details, last GPS location, and parts-required flags. Completed service events are logged against the vehicle record, building a maintenance history that feeds future health scoring and helps identify chronic fault patterns across specific vehicle batches.

    Built for operators with in-house mechanics who are currently tracking maintenance in spreadsheets or paper logs, and for operators whose vendor contract requires documented service intervals for warranty compliance.

  6. Geofencing and city permit compliance

    Zone configuration covers no-ride zones, slow-speed corridors (where the IoT layer throttles the motor to a city-specified limit), preferred parking areas, prohibited parking zones, and permit boundary perimeters. Each zone type carries its own enforcement logic: a speed throttle, a ride-end block, a parking surcharge, or a rider warning notification triggered at the zone boundary.

    Multi-city deployments manage independent zone rulesets per market. Paris regulations don't bleed into a London configuration, and a zone update for one city doesn't require a full platform redeploy. City permit data is version-controlled so your compliance team can produce an audit trail showing the exact zone configuration active on any given date.

    Built for operators in multiple city markets with different permit requirements, for operators facing permit renewal audits that require documented zone compliance history, and for campus mobility programmes with controlled operating perimeters.

03 How we work

How we build micromobility software

  1. 01

    Discovery

    We map your fleet size, vehicle hardware and IoT vendor stack, city permit obligations, current ops workflows, and the specific gaps where your existing platform or manual processes create cost or rider experience problems. We review API documentation for your IoT hardware, identify integration risk early, and agree a fixed-price specification before any development begins.
  2. 02

    Architecture

    We design the data model around your fleet: the vehicle state machine, IoT command flow, zone configuration schema, pricing rule engine, and the API surface your rider app and ops dashboard will consume. AWS IoT Core or a direct MQTT broker is selected based on your fleet size and real-time command latency requirements. City permit compliance constraints are factored into the zone configuration architecture before any code is written.
  3. 03

    Build

    Core IoT integration and vehicle state management ship first, followed by the rider app and then the ops dashboard and pricing engine. Two-week checkpoints with working software give your team early visibility and let you course-correct before the build is complete rather than after. Field-team mobile apps and maintenance scheduling follow in later sprints.
  4. 04

    Launch and handover

    Go-live starts with a controlled zone or vehicle subset before full fleet activation. Monitoring covers IoT command success rates, app crash rates, payment failure rates, and geofencing trigger accuracy. After launch, we handle performance tuning as fleet size grows, city permit updates that require zone reconfiguration, and feature additions as your operations expand to new markets.

Companies we've built for

Vodafone
Nike
Microsoft
Cisco
T-Mobile
Aldi
Heineken
GE

04 Track record

What micromobility and transport businesses get when they work with us

Week delivery for core micromobility platforms
12-18
Software products shipped across transport and logistics
100+
Years building IoT-connected products
6+
Cost delivery agreed before development starts
Fixed

06 Client voices

What our clients say

Three-year average engagement. Founders and operators describing the work in their own words. No marketing varnish.

D
Daniel Reeves
USA flagUSA
CEO

RaftLabs nailed what other agencies couldn't — they started with our business problem and worked backwards to the right product. We were live in 14 weeks.

07 Why us

Why choose us?

  1. 01

    We've seen your problem before

    The industry changes. The broken process usually looks the same. Across 14+ industries and 100+ products, we recognise your problem fast, and we frame the fix around your margin and your operations.

  2. 02

    We own the number, not the ticket

    We measure success the way you do: hours saved, revenue earned, margin recovered. We stay through launch and growth, so the result is ours to own.

  3. 03

    Serious businesses trust us

    Vodafone, T-Mobile, Cisco, Energia, Aldi, Nike. Six years, 100+ products in production, 4.9 on Clutch. Serious businesses keep coming back because we stay accountable long after launch.

08 Questions

Frequently asked questions

Yes. Building the differentiated layer on top of an existing platform (a custom rebalancing dashboard, a city-specific compliance workflow, or a pricing engine the platform's config can't express) is a specific type of engagement we take on. We scope exactly what needs custom development versus what stays on the existing platform during discovery, so you're not paying to rebuild what already works.

We integrate via MQTT, REST, and vendor-specific SDKs, covering Segway IoT, Omni, Comodule, Teltonika, and similar hardware providers. Lock and unlock commands, battery telemetry, GPS polling frequency, and connectivity fallback logic are all part of the integration scope. If your vehicles use a proprietary firmware stack, we review the API documentation and hardware specs during discovery before committing to timelines.

A focused build (a rider app with IoT fleet control and a basic ops dashboard) typically delivers in 12 to 16 weeks. A full platform covering rider apps, fleet rebalancing, dynamic pricing, maintenance scheduling, and city permit data integrations typically runs 16 to 24 weeks. Cost depends on scope, IoT hardware complexity, and the number of city markets. Fixed cost is agreed before development starts.

Yes. Multi-zone geofencing with city-specific no-ride zones, slow-speed corridors, preferred parking areas, and permit boundary enforcement is built into the fleet control layer. When city requirements differ across markets, the system manages each zone ruleset independently so one configuration change in one city doesn't affect another. Zone change history is version-controlled for permit audit purposes.

Use a white-label platform if you are pre-launch or operating under 500 vehicles in a single market. The economics work until the platform's pricing model, configuration limits, or contract terms become constraints. Build custom when your differentiation requires behaviour the platform can't deliver: a proprietary pricing model, a city compliance workflow specific to your permit terms, or a hardware integration the vendor doesn't support. Most operators we work with have already launched on a platform and reached the ceiling of what it can configure.

Yes. Field team apps for rebalancing crews, battery-swap juicers, and mechanics are part of the platform scope. The field app surfaces an assigned task queue with vehicle location, turn-by-turn navigation, and checklist-guided handoffs for each task type. Completed tasks feed back into the ops dashboard in real time so fleet managers see rebalancing progress without chasing the field team for updates.

Ready to build your micromobility and shared transport software?

Tell us what you are building: fleet size, IoT hardware, city markets, and where your current platform falls short. We will scope it out together.

  • Scope and cost agreed before work starts. No surprises. No obligation.
  • Working prototype within 3 weeks of kickoff.
  • Pay by milestone. You see progress before each invoice.
  • 60-day post-launch warranty. Bug fixes, UI tweaks, and deployment support. No retainer.
  • All conversations are NDA-protected.