Stark is Trying to Solve The Last Few Blocks of Scooter Sharing
Share your love
A shared scooter can be charged, working and visible in an operator’s dashboard, yet still miss its next ride. It may be around the corner from demand, left in a quiet part of the service area or parked badly enough that somebody has to deal with it first.
The operator can see the problem. Reaching the scooter is the expensive part.
Stark Vehicles has built a retrofit that lets a person move the scooter remotely. Stabilising arms keep it upright. Cameras and sensors show the street around it. A teleoperator steers through Stark’s dashboard over a mobile connection.
Stark presented the system at Micromobility Europe 2026, which it describes as its public debut. The company remains early: no named external deployment or pilot results were public when this article was prepared. For now, the product can be examined as an operating system in search of its first outside proof.
One block away
A scooter app compresses a lot of work into one map pin. The rider sees a vehicle, reserves it and starts a trip. The operator has spent the day trying to keep enough useful vehicles near the people opening the app.
Demand moves. A morning destination can become an afternoon dead zone. An event can fill one street for two hours. Riders leave scooters where their own trips end, including places that are difficult to see or inconvenient for the next person. A functioning scooter can sit for hours without earning another fare.
Stark co-founder Alec Dian came to the problem from Newt Mobility, the shared-scooter service he ran with his partner in Orlando. During our Charging Stack conversation, he described a familiar gap in fleet operations. Newt’s software could show where scooters were needed, but the vehicles stayed where the last rider left them until somebody moved them by hand.
Fleet software can flag the idle vehicle, estimate demand and assign a rebalancing task. A field worker still has to drive to it, load it or ride it, and leave it somewhere useful. When the required move is a few metres away from a blocked ramp, or a few blocks back to a hub, the trip to the scooter may take longer than the correction.
Riders create their own pressure on that system. Dian described the customer who would have paid for a trip but chooses another brand because its scooter is closer. Charging Stack’s hosts had done exactly that while travelling around Berlin. Stark has no public dataset showing how often operators lose a ride this way, but Newt gave its founders enough experience of the problem to spend years building a physical answer.
Parking adds a second queue of work. A photograph, geofence or rider warning can tell an operator that a trip ended in the wrong place. It cannot rotate the scooter, clear the pedestrian path or put the vehicle inside a marked area.
The retrofit
Stark adds hardware and software to compatible fleet vehicles instead of asking an operator to replace the scooter underneath them. Its operator page shows the current system on a Segway Max. That identifies the platform on display, not a commercial partnership with Segway.
Charging Stack first saw the scooter moving at the Berlin show. The stabilising arms were the obvious part: they extended from the lower body before the riderless scooter moved, then retracted when it returned to normal use. People nearby stopped to watch, but the demonstration also showed why the retrofit is mechanically involved. Keeping a two-wheeled vehicle upright is only one part of the job; the same hardware has to disappear far enough that it does not interfere with the next rental.
According to Stark’s hardware page, deployable arms hold the scooter upright during remote driving and retract for an ordinary rider. A steering mechanism turns the handlebar remotely and disengages in rider mode. Front and rear cameras, LiDAR and proximity sensors feed the remote view, while an onboard computer and 5G or LTE connection carry video, telemetry and commands.
SYSTEM BREAKDOWN
CS / 01
What Stark adds to a fleet scooter
One retrofit. Seven layers.
Hardware on the scooter connects to a human teleoperator and the fleet software already running the operation.
07
FLEET LAYER
Fleet integration
API connecting fleet software to Stark
06
CONTROL LAYER
Operator interface
Live camera feeds, telemetry, controls and task queue
05
NETWORK
Connectivity
5G/LTE modem, Bluetooth and GPS
04
PERCEPTION
Vision and sensing
Front and rear cameras, LiDAR and proximity sensors
03
VEHICLE CONTROL
Steering
Remote mechanism that disengages for normal riding
02
VEHICLE CONTROL
Stabilisation
Deployable arms that retract for rider use
01
BASE VEHICLE
Segway Max
Configuration shown publicly by Stark
REMOTE MOVEMENT
Fleet task
→
Teleoperator
→
Network
→
Scooter
The software has three layers: code on the vehicle, a teleoperator dashboard and an API. When a fleet system sends an action, Stark turns it into a task. The teleoperator sees the scooter’s location and destination, opens the camera view and takes control. Parking corrections and rebalancing use the same sequence; the assignment changes.
Dian described two ways those assignments could arrive. The end of a ride might trigger an inspection task, asking the teleoperator to check the camera view and correct the parking if needed. A fleet manager could also send a direct instruction to move a particular scooter to a hub or another zone. The operator is working through a queue rather than choosing vehicles at random from the map.
In the version discussed during the podcast, the teleoperator drove with an Xbox controller. That detail makes the job easy to picture, although the hard engineering sits between the controller and the wheels. Dian said remote balance and steering had to work without spoiling the scooter for its paying rider. The added systems control the steering and throttle during a remote move, then disengage or retract before the customer rides. Cellular latency was another problem the team spent time on.
A human remains at the controls. Stark talks about increasing autonomy later, but someone still watches the feed, accepts the task and drives each scooter today.
Stark says the software monitors network quality and restricts control if the connection becomes unstable. It also lists encrypted communication, obstacle avoidance and 360-degree vision. Those systems have to work together while the scooter is moving among people, parked vehicles, kerbs and street furniture.
Built inside Newt Mobility
Dian and his partner developed Stark while operating Newt in Orlando. Stark’s About page puts their shared-scooter experience at nearly seven years and the research period at five. The interview used a roughly six-year operating timeline. “Several years” is the accurate description until the company reconciles the dates.
That period included the ordinary physical work behind a fleet. Dian had moved scooters overnight, handled parking corrections and watched charged vehicles sit outside demand. The product began inside those shifts, not as a speculative autonomy project.
Newt also gave the team somewhere to test. In the interview, Dian said the retrofit had been used inside its own fleet before Stark took it to the trade show. That let the founders work on the awkward interaction between remote-driving hardware and a scooter that still had to survive daily rentals. It also kept the early evidence inside a fleet they controlled, which is why an outside operator now matters.
It also explains the decision to retrofit. Operators have vehicles, spare parts, technician training and maintenance routines tied to their existing platforms. Changing the scooter can change all of that. Stark tries to add remote operation while leaving the normal ride familiar.
The approach saves the operator from adopting a separate vehicle platform, but it gives Stark an integration job for every model it supports. Mechanical packaging, electronics and service procedures vary. Stark says it is concentrating on select newer-generation scooters and manages installation itself.
For a fleet workshop, fault-finding will cross several layers. A problem could sit in the original scooter, the added steering or stabilisation hardware, a sensor, the onboard computer, the mobile connection or the dashboard. Stark’s commercial package will have to assign responsibility for diagnosis, spare parts and downtime. An operator will also need the installation time, warranty and maintenance schedule before it can cost the system properly.
What teleoperation takes off the street
Parking correction is the shortest job Stark describes. If a working scooter blocks part of a walkway, a remote driver may be able to move it into the correct bay without waiting for a field visit. Returning it to a nearby hub or depot takes longer. Rebalancing sends it towards likely demand. Rider-requested delivery tries to create a trip by bringing the vehicle to the customer.
Newt tested that last idea through its app. Dian said a rider could request a scooter and enter a destination. The system would look for a nearby vehicle with enough battery to reach the rider and complete the intended trip, skipping a closer scooter if its charge was too low. The remote drive used some of the battery before the customer stepped on, so the selection had to account for both legs.
That is a different operating job from moving a scooter back inside a parking bay. It combines dispatch, battery state, delivery time and the risk that the customer changes plans before the scooter arrives. It could also produce a paid trip that would never have happened if the rider had opened the app and found an empty map.
Fleet staff still inspect, clean and repair scooters. They recover damaged vehicles, deal with vandalism and handle battery work that cannot be completed remotely. Dian was open about that in our interview. Stark is aimed at a smaller set of jobs where the scooter works and mainly needs to change position.
Even within that set, the operating conditions differ. A depot or private campus has different road users and permissions from a public street. Correcting a scooter’s angle by two metres bears little resemblance to driving it several blocks through pedestrian and cycling traffic.
A 2019 modelling paper on self-repositioning scooters found that the benefits depended heavily on infrastructure and deployment assumptions. It did not study Stark, and Stark uses a human driver, but the warning travels well. Route length, permitted space and the time taken for each move can change the result.
Remote operation changes where some labour happens. A teleoperator needs training, a workstation, a reliable connection and a procedure for stopping a task. A failed remote move may still send a field worker to the same scooter.
The timing of the task matters too. A parking correction may need attention within minutes because it blocks access. Rebalancing can be scheduled around demand. A depot return may be worth doing overnight, when the street is quieter, even if the trip is longer. Stark’s task queue will have to reflect those priorities because a teleoperator can only drive one scooter at a time.
The operator math
Dian told us that Newt averaged roughly two rides per scooter per day before the team put greater effort into parking correction and repositioning. He said the figure rose to around four. During a test that let riders request scooter delivery through the app, it reached as high as nine.
The numbers come from Newt’s internal operation. There is no published sample size, fleet size, test period, trip mix or full cost breakdown, and no external operator has reported the same result with Stark’s commercial retrofit. They show what prompted the company to pursue the product, not what another fleet should put into its budget.
Dian said the repositioning case produced an internal payback estimate of roughly 12 months, while the delivery test suggested a period under four months. Those estimates move with the utilisation assumption. If a delivered scooter does not generate the extra trip, the cost of the remote move remains and the revenue disappears.
Stark’s public ROI calculator gives a view of its model. The example uses monthly assumptions of $50 for software, $10 for connectivity, $25 for additional maintenance and $40 for teleoperation per scooter. It adds a $25 saving from reduced manual rebalancing and models revenue increases of 200 to 400 percent for on-demand delivery.
These are calculator inputs rather than a public price list or customer result. Hardware, installation, insurance, training and failed movements also sit in the operator’s cost base. A large utilisation assumption can make the payback period collapse on screen.
The comparison is simple enough. Run the same fleet before and after the retrofit and see whether extra paid rides and fewer field visits outweigh the time and cost of teleoperation. Safety incidents belong in the same report. The result will probably look different in a tourist centre, on a university campus and across a spread-out city fleet.
On city streets
Municipal representatives who spoke with Dian at Micromobility Europe kept returning to parking and sidewalk clutter. A scooter that can be moved remotely gives the operator a quicker response than a warning sent to the last rider or a field task waiting in a queue.
It also puts a riderless, remotely controlled vehicle into public space.
A city or site owner will want to know where it travels, how fast it moves, what the remote driver can see and how it stops when the connection fails. Operator training, incident reporting, insurance and liability become part of the deployment. Stark’s sensing and network safeguards are relevant here, but component lists are not a permit or a safety record.
Dian described the legal treatment of teleoperated low-speed vehicles as a grey area and argued for a defined permit route. As of 25 September 2026, the reviewed material included no named municipality, public permit, insurance arrangement or independent safety evaluation for Stark.
Closed sites may offer simpler conditions. Public-street operation will be local by definition. The route, vehicle classification and city rules matter, and an approval in one place will not travel automatically to another.
For a transport department, the useful evidence will be visible on the street: how quickly a blocked path is cleared, whether the scooter reaches the correct parking area and how often a remote task fails. Operators will be looking at many of the same events from the cost side.
After the demo
Stark has shown that its retrofit can turn a conventional fleet scooter into a remotely driven one. It has also spent years with the manual work the product is meant to reduce.
The interview referred to an unnamed pilot planned for August. No public announcement identifying the operator, city or result had appeared in the sources reviewed for this article, so the pilot remains unconfirmed.
At Newt, the team already knew where its scooters needed to go and sent people to move them. The next useful evidence is another operator’s daily shift report, showing what a remote move cost against sending somebody into the field.
