Comodule is Building the Digital Layer Behind Connected e-Bikes

Comodule puts hardware, cloud software, apps, and controls behind connected e-bikes. Security is the obvious use case. The bigger question is what brands and riders get from that connection after the sale.

Locking an e-bike through an app takes a second. Underneath that tap, a command passes through the software and connectivity layer to the bike. With compatible hardware and drivetrain integration, it can immobilise the drive unit, arm an alarm, and switch on movement alerts.

That small action is a good way into Comodule.

The Tallinn-based company builds the hardware and software behind connected e-bikes. It says it has connected 800,000 of them. We could not independently verify that number, but it gives a sense of the scale Comodule claims for technology that most riders will never see.

When we spoke with Timo Saabas of Comodule, GPS was the starting point for a much bigger discussion. Who controls the app? Who gets to use the data? Who supports the software five or ten years from now? And does the rider keep getting enough value to leave the connection switched on?

Security makes the case easy to picture. Service, diagnostics, updates, and the relationship between the brand and rider are where the story gets more complicated.

Comodule can put a bike online. The test is whether that connection stays useful after the bike leaves the shop.

The module is only the entry point

Location can make Comodule look like a tracker supplier. The company actually works across most of the connected-bike system.

An embedded IoT module links the bike and compatible components to Comodule Cloud through cellular and Bluetooth connectivity. A brand can use Comodule’s white-labelled Companion App, manage vehicles through a web portal, build its own interface through APIs and a Bluetooth SDK, or connect other fleet and service software.

The Companion App can carry the bike manufacturer’s branding. Comodule lists tracking, digital locking, movement alerts, live location sharing, theft reporting, bike sharing, and a digital bike passport among its rider functions. The exact mix depends on the bike and the components connected to it.

The Comodule Portal is built for product and operations teams. It shows vehicle status, battery and speed information, remote commands, location history, credentials, and app and model management. APIs bring vehicle data and controls into customer-built software, while the Bluetooth SDK supports direct communication between a phone and the module.

The same connection has to work for people with very different needs. A rider wants a few dependable controls. A workshop needs enough diagnostic context to prepare for a repair. A product team needs settings and update tools. A fleet operator needs to know which bike requires attention.

For fleets, Comodule’s shared-mobility product can provide location, usage, module health, battery performance, error codes, and cellular status. Operators can feed that information into an existing fleet platform instead of replacing the software they already use.

Saabas described three broad routes when we spoke: use Comodule’s app and management tools, build a customer-owned experience on its interfaces, or connect the hardware to another software platform. That gives brands some room to decide how much they want to build themselves.

The module may start the project, but the longer commitment sits elsewhere. Someone has to run the cloud service, maintain the app, support the cellular connection, ship security fixes, and keep the system working across the life of the bike.

Security is where the value becomes obvious

Theft protection gives riders the clearest reason to care about an embedded connection. A Bluetooth tag can help indicate where an item may be. A connected bike can combine location with alerts, communication, and control of compatible vehicle systems.

Comodule’s security tools include GPS tracking, movement alerts, live location sharing, theft reporting, digital locks, alarms, and drive-unit immobilisation. The system can tell a rider that the bike has moved, make noise to draw attention, and restrict electrical assistance. The aim is to make the bike harder to use and less attractive to resell after a theft.

The useful difference is the number of chances to intervene. A movement alert can reach the rider before the bike disappears. An alarm can change what happens on the street. An immobiliser can stop the electrical system from working as intended. Location then helps with the response that follows.

None of this makes a bike impossible to steal. A mechanical lock, network coverage, and battery status still matter. The rider may need to activate the feature, notice the alert, and work with a recovery or insurance service. The result depends on the bike integration and the people responding around it.

Comodule’s Christiania Bikes case study shows both the promise and the limits of the public evidence. The company reports that 90 percent of theft attempts that triggered alerts were stopped or ended in recovery. It does not publish the denominator or an independent methodology, and the security system had to be activated. We see it as a useful customer example, not a general recovery rate.

Saabas described security as the main rider use case. He also separated a standalone tag from networked tracking and from a connected system that can reach the vehicle electronics. A map pin tells you where to look. An alert tells you something is happening. An immobiliser changes what the thief can do with the bike.

That combination is what makes the security story convincing. The technology earns its place when it gives the rider a chance to act.

The post-sale relationship is a product decision

Once security gives the rider a reason to connect, the brand has to decide what to do with that channel.

Bike brands have traditionally relied heavily on dealers after purchase. The dealer assembles the bike, explains it, handles maintenance, and often becomes the first call when something fails. Connected products add another route. A brand can send security notifications, expose diagnostics, update firmware, adjust supported settings, and communicate about service through its own interface.

Saabas told us that many brands still treat connectivity mainly as a bill-of-materials cost. His point was that the longer commitment sits in services and the customer relationship. The practical questions are simple: which app does the rider install, which account do they create, and who decides what the software can do next?

Comodule offers a white-labelled app and tools for customer-built interfaces. It also argues that brands risk giving component suppliers too much control over the digital layer. This is Comodule making its own commercial case, not a neutral assessment of every drive-system platform. Even so, the issue matters for any OEM choosing a connectivity provider.

That choice affects the interface, data model, feature roadmap, and the cost of switching later. It also decides who gets the support call when the app, cellular connection, or security feature stops working. The quickest route to market can create dependencies that are easy to miss while the bike is still in development.

An OEM therefore needs to ask about the operating model as well as the hardware. Can the brand export its data? Who owns a security incident? How long will software and cellular service be supported? What happens if the supplier changes strategy? Those questions can matter long after the module has been designed into the frame.

The dealer still has a role. Better diagnostics could help a workshop prepare for a repair or separate a software fault from a hardware problem. The app also needs rider activation, consent, and a reason to keep using it. Installing an account on day one does not create a lasting relationship by itself.

A connected bike can give the brand a direct service channel alongside the dealer. Whether riders value that channel comes down to reliability and useful features, not the presence of an app icon.

Data is useful when someone acts on it

Connected-bike data has value when it changes what a team does next.

A service team can inspect location, usage, connectivity status, battery information, and error data when the bike exposes them. That might support a workshop diagnosis, a remote setting change, a firmware update, or a decision to bring the bike in.

Product teams can use aggregated usage and performance patterns to test assumptions about how their bikes are used. They might find that riders ignore a particular assistance mode, that one battery issue keeps returning, or that the same warning repeatedly leads to a support request. The information is useful only if someone owns the follow-up.

This is where many connected products become less impressive than their dashboards. Collecting telemetry is a technical task. Turning a repeated fault into an engineering priority, a workshop fix, or a clearer rider message is an organisational one.

Fleet operators feel that difference quickly. Location, battery performance, error codes, and module health can help a team decide which bike to retrieve, charge, or repair first. We have seen the same issue in fleet operations software: raw data becomes useful when it points to the next job.

Brands can also use the connection to send security notifications, service reminders, and other messages tied to ownership. Insurance, recovery, battery-health services, subscriptions, and paid software features are possible ways to make money from the system. We found no public evidence that these services already produce material recurring revenue for Comodule’s customers.

Comodule says customers own their fleet and user data in its shared-mobility setup while the company acts as a data processor. That is Comodule’s stated position. Consumer deployments can use different contracts and legal roles, so brands still need to read the terms project by project.

Saabas called data underused in the e-bike sector. We agree with the direction of that argument, but the answer is not another dashboard. It is a product, service, or operating decision that would have been harder to make without the connection.

Astra is meant to make the first step easier

Deep connectivity can require vehicle integration, software work, testing, support, and a long-term operating budget. Smaller brands may want tracking or security without building a large digital team.

Comodule introduced Astra on 1 September 2026 as a module intended to lower that barrier. The company says customers can configure it for anything from tracking to deeper drivetrain integration. It claims positioning accuracy of up to 2.5 metres through Wi-Fi Locate, up to 12 months of idle battery life, and Cat-1 bis cellular connectivity.

Those are Comodule’s maximum figures. The company has not published independent field tests or full test conditions. We also could not find public pricing, minimum order quantities, complete hardware specifications, certifications, or a typical integration timeline.

Comodule says pre-orders are open and production is planned to ramp in 2027. Astra is still a product plan, not proof that a smaller brand can already add connectivity quickly or cheaply at volume.

The pitch is easy to understand: start with a narrow use case, then connect more of the bike later. Whether that works will come down to cost, compatibility, engineering time, reliability, support, and how long Comodule keeps the cellular and software service running.

Why this matters beyond Comodule

The European bicycle market makes the timing worth a closer look.

European Cycling Industries reports that Europe produced 10.82 million bicycles and electric pedal-assisted cycles in 2025, broadly stable against 2024. Sales totalled 15.618 million units, down 2.6 percent, while sales value fell 0.84 percent to €18.252 billion. The association described inventories as progressively normalising after the market correction.

Those figures do not tell us whether connected features improve sales, retention, or profitability. They do show a market where brands cannot count on exceptional unit growth. The bikes already on the road, and the relationship with the people riding them, deserve more attention.

Security, service, and useful software give a brand another way to create value after the initial purchase. They also create work. Apps need updates. Cellular connections cost money. Security issues need an owner. Riders need help when a feature fails.

Connectivity also gives brands another place to stand apart in a sector where many bikes share drive systems and other major components. A vertically integrated connected brand such as Cowboy can shape the bike, app, support model, and service experience together. A brand assembling systems from specialist suppliers has to decide which parts of that experience it wants to control.

For riders, the connection has to produce practical security and support. For OEMs, it creates a direct channel and a new set of responsibilities. Dealers may get better diagnostic information while part of the customer interface moves toward the brand. Fleet operators can use vehicle status to manage uptime. Component and software suppliers can gain influence over the interface and data model.

A similar choice came up when we spoke with MicroFleet: give customers an API, or provide more of the operating system around connected light electric vehicles. Comodule faces a version of that question inside the bike. Its customers have to decide how much of the experience to adopt and how much to build themselves.

Connectivity will not rescue a poor bike, weak repair support, or unreliable electronics. It can make a good product easier to protect, service, and improve. That is a useful contribution, but it has to work consistently enough to justify the extra cost and responsibility.

What we still want to know

Comodule’s public material tells us a lot about what the system can do. It tells us much less about how often those features change outcomes across several customers.

Do riders keep using it?

What share of owners activate the app and connected security? How many still use those features after six or twelve months? The Christiania result is promising, but independent evidence across more brands would give us a better picture of theft, recovery, insurance claims, and rider confidence.

What does integration really cost?

A smaller brand needs to know what tracking, security, diagnostics, or drivetrain control costs to add and operate. It also needs a realistic timeline, internal staffing requirement, minimum order quantity, and support model. Without those numbers, it is hard to judge how accessible the system is outside large programmes.

Who owns what?

Comodule’s public pages describe APIs, data access, and customer control. The contract still has to settle controller and processor roles, consent, retention, deletion, export, and portability. A brand also needs to know whether it can move its data and services if it changes provider.

Who supports the bike in year eight?

E-bikes can stay on the road longer than a typical phone upgrade cycle. The module, cellular service, firmware, app, and security process need support across that life. Comodule maintains a public vulnerability disclosure policy covering its modules, cloud services, APIs, Portal, Companion App, and SDK. The policy explains how to report a problem. It does not say how long every product will receive updates or cellular support.

Astra brings another set of questions. We still need field evidence for its positioning, idle battery life, compatibility, certification, pricing, production schedule, and reliability.

These are normal questions for any connected product expected to stay in use for years. They also decide whether connectivity becomes useful infrastructure or an expensive feature that ages badly.

Why Comodule matters

Comodule is worth watching because it sits behind a decision many bike brands still treat as a hardware line item. Once a bike has an app, cellular connection, remote controls, and ongoing software, someone has to look after that relationship for years.

The module earns its place when the connection makes the bike harder to steal, easier to diagnose, simpler to update, or more useful to the rider and workshop. The brand gets value when it can run that service without losing control of the customer experience or locking itself into terms it cannot live with.

Comodule has built enough of the system to make those questions practical rather than theoretical. What we need to see next is how reliably the system improves security, service, and operating costs across different customers, bikes, and markets.

Putting a bike online is the easy part. Keeping that connection useful after the sale is the test.