DOC

MICROMOBILITY SOFTWARE TECHNOLOGIES LTD

Software for shared electric fleets

We create and manage the platform layer that supports the operation of large, distributed fleets of network-connected e-scooters and e-bikes: task dispatching, telemetry, integrations, remote diagnostics and a field tool that contractors use every day.

Entity: Private Ltd
Registered: Nicosia, Cyprus
Domain: Fleet software
Status: Operating

Fig. 01Dispatch console. Live fleet map, task queues and contractor status in one view.

Fig. 02Field tool in development. The PWA contractors use is designed and iterated in-house.

Fig. 03Engineering floor. Telemetry, integrations and diagnostics maintained by one team.

Abstract

Micromobility Software Technologies Ltd is the engineering entity behind the Micro-mobility Operating System (MOS) — the platform that shared-fleet operators and their 3PL partners run their daily operation on.

Our work sits between the vehicle and the operator: every day the platform processes thousands of generated tasks, we automatically group them by type and instantly deliver ready solutions, complete with confirmations, statuses and analytics.

Scope

Why the platform layer exists, and what it is accountable for.

Shared mobility is growing on the back of urbanisation, congestion, low-emission policy and smart-city programmes. Operators enter new markets fast and delegate operations to local 3PL partners.

Those partners inherit the hard part — charging, repairing, redistributing and accounting for a distributed electric fleet, every day, at city scale. Without a platform, that work does not survive contact with growth.

Our brief is narrow and technical: make a fleet of thousands of units behave like one managed system, and make it possible for an operator to launch a new city without rebuilding the software each time.

System

MOS is an operating layer, not a dashboard. It ingests telemetry, forecasts demand and discharge, generates and routes work, and records what happened to every asset.

02.1IngestDirect API integration with the operator's core platform brings in per-unit telemetry in real time — charge, location, connectivity, fault codes.
02.2DecidePredictive models forecast discharge and demand by city zone from historical data, weather and time of day. Rebalancing targets follow from the forecast, not from intuition.
02.3DispatchWork is generated, prioritised and routed to the right B2B contractor automatically, with assignment logic that guarantees the task and its status stay attached to the right unit.
02.4ExecuteField crews work in a progressive web app — no store install, offline-capable, photo and geotag captured at the point of work.
02.5AccountEvery action writes back to the asset record. Daily reporting turns it into operational KPI and unit economics.

Task streamExample flow

07:41:19SWAPlow charge detected#1000

07:41:33MAINTcontroller replaced#1977

07:41:50LOGIutilisation recalculated#2954

07:42:10DIAGfalse battery fault cleared#3931

07:42:33RECOVlast position resolved#4908

07:42:44SWAPunit back in service#5885

07:42:58MAINTbrake service closed#6862

07:43:15LOGIunit moved to target zone#7839

07:43:35DIAGgps drift corrected#8816

Modules

Every field task belongs to one module, and every module writes back to the same asset record.

Ref	Module	Function	Inputs	Outputs
03.1	Swap / EnergyBattery replacement	Plans and dispatches battery swaps across the fleet, ordered by state of charge, forecast demand and contractor position.	SoC telemetry, demand forecast, crew location	Swap tasks, energy cost per unit
03.2	MaintenanceRepair, service, parts	Repair queues, scheduled service and component stock control, with one continuous record per asset from fault report to return to service.	Fault codes, field reports, stock levels	Work orders, parts consumption
03.3	LogisticsFleet redistribution	Rebalancing tasks derived from demand heatmaps, so units stand where the next ride actually starts.	Demand model, utilisation history	Relocation tasks, target zones
03.4	Lost & FoundAsset recovery	A dedicated interface and search logic for locating and recovering units that have dropped out of the active fleet.	Last known position, connectivity history	Recovery tasks, loss reporting
03.5	IT Support & DiagnosticsPlatform reliability	The internal tool our engineers use to diagnose and clear software and connectivity faults remotely, before a healthy unit is pulled off the street.	Module logs, firmware state, error codes	Resolved faults, avoided service trips

Telemetry

What the system watches, and the shape of the work that comes out of it.

Task volume dispatched by hourExample day · relative

0006121823

Fleet state of charge, share of unitsExample snapshot

0–20%6%
20–40%11%
40–60%19%
60–80%28%
80–100%36%

Needs swap
Watch
In service

Fig. 04Telematics module. The source of charge, position, connectivity and fault telemetry.

Fig. 05Redistribution run. Relocation tasks derived from the demand model.

Reliability

Most fleet downtime is not mechanical. It is a unit reporting the wrong state, a module that lost signal, or a task that reached the wrong contractor.

05.1Connectivity and GPSDiagnosing and clearing signal loss and GPS drift, so a working vehicle is not reported as lost.
05.2Firmware controlCentralised rollout and version control of on-vehicle software, keeping every module behaving identically across the fleet.
05.3Data verificationDetecting and correcting mismatches in the QR ↔ IoT module ↔ VIN chain — the source of most phantom fleet records.
05.4Battery diagnosticsAlgorithms that recognise false battery communication faults and stop a healthy unit being sent for service.
05.5Task integrityAssignment logic that guarantees each task reaches the correct contractor and is tracked through to completion.

Architecture

Three tiers and the links between them. Each row is one contract.

01Fleet
Vehicles and the operator's core platform — the source of truth about hardware.
02MOS core
Ingest, decide, dispatch, account. All business logic lives here.
03Consumers
Field crews in the PWA and managers in the dashboard.

Ref	From	Dir	To	Channel	Payload
06.1	Vehicle IoT moduleFleet	→	MOS core	Telemetry	Charge, position, connectivity, fault codes
06.2	MOS coreCore	→	Vehicle IoT module	Firmware	Version rollout and module configuration
06.3	Operator platformFleet	↔	MOS core	API	Fleet state, trip and asset records
06.4	MOS coreCore	→	Field PWA	Tasks	Swap, repair, relocation and recovery work orders
06.5	Field PWAConsumers	→	MOS core	Evidence	Status, photo, geotag, parts consumed
06.6	MOS coreCore	→	Dashboard	Metrics	KPI, utilisation and unit economics
06.7	MOS coreCore	↔	Digital twin	Model	Scenario inputs and forecast results

06.0Modular cloud architecture. Every link above is a contract: one source, one direction, one payload — which is what makes a module replaceable without touching the rest of the system.

Stack

Layer	Technology	Role
Field client	Glide	Progressive web app for contractors — offline-capable, no store install
Automation	Google Apps Script	Business logic, scheduling and integration glue
Integration	Direct API	Real-time telemetry from the operator's core platform
Storage	NoSQL-style stores	Structured, schema-flexible records for heterogeneous telemetry
Reporting	Automated daily reports	Operational KPI and unit economics
Modelling	Digital twin	Live model of the fleet for scenario testing without touching operations

Entity

Registered in Cyprus, working with operators and their 3PL partners across Europe and beyond.

micromobility.contact@gmail.com

Send the city, the fleet size and the launch window. We will come back with the integration scope, the field workflow and what the platform would run for you.

Legal name: MICROMOBILITY SOFTWARE TECHNOLOGIES LTD
Registry: Private Limited Company · Republic of Cyprus
Jurisdiction: Nicosia, Cyprus
Address: Tompazi 70, 1055 Nicosia, Cyprus
Time zone: EET · UTC+2