Fleetio's fleet maintenance and optimization platform helps businesses keep their vehicles on the road, providing a centralized system for coordinating driver inspections, work orders, and repairs across fleets ranging from local delivery outfits to logistics giants. Growth has been steady and compounding: the company has scaled consistently year over year and is now considered a leader in its space.
Mobile plays a fundamental role in the business — two-thirds of Fleetio's users are on mobile. Drivers and technicians out in the field, the people doing pre-trip inspections, logging defects, and coordinating repairs from the side of the road, are the primary users of the product. The mobile app does more than just deliver an experience; it's also a data ingestion pipeline: every inspection completed and every defect reported on a phone becomes input for the analytics Fleetio delivers back to fleet managers.
That centrality is part of why Fleetio went fully native a few years ago, refactoring away from an Ionic app to native iOS (Swift) and Android (Kotlin). The performance and hardware access demands of camera, location, and barcode scanning had made cross-platform frameworks too constraining. Around the same time, three separate apps (FleetioGo, FleetioMove, and FleetioParts) were consolidated into one unified mobile app. By this time, the team had grown to roughly fourteen engineers across iOS and Android, plus QA, PMs, and design, with somewhere between 15 and 30 people involved in any given release. And they had committed to releasing weekly on both platforms — faster than the every-other-week cadence most mobile teams settle into.
Which raised a question: when releases happen every week, on both platforms, with a team that's grown by 4x and just been reorganized into vertical squads, who actually runs them?
Challenge
Three years of weekly releases on a growing team, all running through one person
For most of Fleetio's mobile history, the answer was a single person. The work spanned Jira, GitHub, CI/CD, App Store Connect, and Google Play Console, and nearly all of it was manual.
The hardest part wasn't the technical mechanics. It was the coordination. The release owner wasn't the engineer cutting the build, so the only options were to wait for word that a build was ready or go hunting through each engineer's workflow to find out. Communicating progress to PMs, QA, and leadership meant repeating the same status update across a dozen Slack threads. And coordinating regression testing meant pinging QAs one by one the moment a build was ready. It made for a constant, stressful scramble — waiting on people, chasing down information, sometimes getting the wrong information and losing most of a day to running things down.
As Fleetio's mobile team grew from a tight group of four engineers to one spanning multiple squads, the inconsistency got worse. Around the same time, the team restructured from a centralized mobile guild into vertical squads, most of them mixing web and mobile. That made release ownership harder to keep concentrated in one place, and meant new engineers were rotating onto release duties they didn't run often enough to remember. As more people cycled through the process, small deviations crept in — a release might go out early or late, or a usual step might get missed. What they needed were guardrails.
Things shifted when Fleetio hired a new Director of Mobile, whose mandate included getting the release process under control on day one.
Solution
Guardrails anyone could follow, not tribal knowledge everyone had to memorize
Once the team started looking for a fix, the shape of what they needed was clear: a shared system, rather than another person to hold it all in their head. Runway came up not long after, recommended by a new mobile leadership hire who had encountered it in a prior role. With the process straining at the seams, trialing it was an easy call.
Brandon Yates, Fleetio's senior mobile platform engineer, led the rollout. He'd been at Fleetio for four and a half years and would end up implementing Runway from scratch. The technical side came together quickly — Brandon turned on Runway's automations for the pieces the team had long wanted to offload: branch cuts, version bumps, release tagging, and the handoffs between GitHub, Jira, CI/CD, and the app stores. A few steps were deliberately kept manual, not because Runway couldn't automate them, but because the team wanted a human touching the process at key checkpoints for quality's sake.
"The technical aspects we were able to automate pretty quickly. We kept a few things manual just to keep people awake at the wheel. With Runway we could have completely automated everything, but we wanted to inject some human interaction at key points, just to be aware of what was happening."
Brandon Yates
Senior Mobile Platform Engineer
But the harder problem Runway was asked to solve was the human one. Fleetio runs a six-person release captain rotation per platform, which means any given engineer only cuts a release every six weeks. That's a lot of time to forget how things work. Runway's release overview, customizable checklists, and color-coded steps turned out to be exactly the right scaffolding for a rotation that had to stay sharp without staying constantly hands-on.
"The little checklists you can add, and the color-coded steps — it's very easy to see if you've missed a spot. In my experience working at various companies, using Runway has been the smoothest release experience I've had."
Ben Conway
Software Engineering Manager
Runway also became the team's hub for the integrations that already powered their workflow, with release tagging (a persistent source of pain, and a SOC 2 requirement) now handled automatically on every release.
"Runway does the tagging for us, and it's been integral to the way we track the content of our releases. It has a really curated list of integrations. When we switched QA tools, the new one was already supported."
Brandon Yates
Senior Mobile Platform Engineer
Results
75% less time per release captain, and hundreds of developer hours back
With Runway in place, the time a release captain actually spends running a release has fallen sharply.
"Releases used to take two to four hours for an experienced engineer, and longer if something went wrong. Now cutting a release takes five minutes, and shepherding it along the way takes a few more. We've brought a release captain's time commitment down by about 75%. Hundreds of developer hours a year that Runway saves us."
Brandon Yates
Senior Mobile Platform Engineer
That reclaimed time translates directly into release velocity. Last year, Fleetio shipped 98 releases across iOS and Android, essentially every week of the year (minus a planned December pause). The team now regularly ships more than once a week when they need to, and hotfix turnaround has gone from several days to a few hours.
For engineers rotating onto the captain role, the shift has been just as meaningful. Ola Adie, who joined Fleetio recently to cover the iOS side alongside Brandon, found himself running releases without the usual ramp-up period that used to come with learning a bespoke process. New engineers typically shadow during their first 90 days and start cutting releases shortly after, a curve that would have been much steeper without Runway's visual scaffolding.
"When I joined, the process was easy to follow. Runway makes it much easier to onboard and understand what the process looks like when you're the release captain."
Ola Adie
Mobile Platform Engineer
For the release owner who had carried the process for years, the change meant getting time back for the rest of the job. Rather than needing to constantly organize and update QAs, the team could point testers at the release in Runway and let them see for themselves whether a build was ready — no more individual pings, and more autonomy for QA.
Asked what would happen if Runway disappeared tomorrow, the team said the impact would be "astronomical," and they'd essentially have to retrain everyone from scratch.
"It'd be similar to an airport control tower not being available and everyone just figuring out how to take off by themselves."
Ben Conway
Software Engineering Manager
