Citydrive’s Release
Five management decisions in Citydrive’s case study that left me with questions. On planning, communication, working across teams and measuring results.
Disclaimer: I’m looking at publicly shared professional case studies, not judging their authors. This is me thinking out loud about how well the conclusions hold up and what I can pick holes in. I’m also testing the idea that a company’s reputation and a post on a well-known platform automatically make its advice sound.
On 21 March 2025, Daniil Sukharev about Citydrive published a Habr article titled “From Monoliths and Chats to FMS and FMS App: Taking Management of a 19,000+ Car-Sharing Fleet to the Next Level”. If you’re curious, you’ll find it. Daniil describes building a fleet management system and a mobile app. The team delivered an MVP in three months and revamped the processes over three quarters. An impressive result, with some interesting technical work behind it. I wouldn’t rush to adopt all the management decisions, though.
1. Estimation and planning
“We dropped traditional estimates.”
Fewer meetings. Oh, tempting. But dropping backlog refinement and dropping effort estimation are two different decisions. The article mentions Jira, balancing workloads and a three-month MVP deadline. There’s almost nothing about financial planning.
For an internal product with a dedicated team, that might work. In client-funded development, you won’t get far without estimating scope and cost. The proposal won’t write itself, and team enthusiasm won’t make a fixed budget grow. I’m all for dropping unnecessary ceremonies. Dropping control over effort is another matter.
2. Communication
“All communication went through me.”
The product manager handled all stakeholder communication so developers wouldn’t be interrupted. Understandable for a small team, but it creates a single point of failure.
The product manager gets ill, takes a holiday or misses a technical detail, and communication stalls. Information also gets filtered through a middleman’s interpretation. I’m all for screening out unnecessary requests. Specialists still need to be able to talk directly, especially when two developers can sort something out in five minutes without a third person involved. Let’s hope it didn’t take the twelve labours of Hercules.
3. Change management
“Rebuild the app.”
The article mentions a 25-page spec, nearly 300 app screens and several changes in direction. A familiar story. I’d just like to know what that flexibility cost.
Changing requirements means rework, dependencies and extra checks. We don’t know how much of the completed functionality was affected. Being able to pivot quickly is useful when you’re tracking the cost of the pivot, rather than discovering it afterwards.
4. Working across teams
“We’ll do it ourselves.”
When other teams couldn’t pick up a change, the author offered to have his team do it instead. This is where my favourite question about ownership comes in. I don’t even need to say it out loud.
Another team’s system has an owner, technical constraints and ongoing support commitments. Making the change yourself might speed up your release while leaving someone else to deal with the consequences. I’d rather agree on priorities, collaboration and who owns the result afterwards. Persistence is a useful soft skill. Working around someone else’s backlog is harder to sell as a universal best practice.
5. Measuring results
“Ready on time.”
The MVP launched. There are very few management metrics to help assess the approach, though. No delivery speed trends, rework figures or team workload data. Nobody has to disclose internal financials. Are relative improvements classified too?
The author goes into detail on architecture, testing and automation. Those could have contributed a great deal to the result. I wouldn’t attribute the success to dropping estimates and routing communication through one person.
Launching on time is a team achievement. If the case study is about management decisions, show what those decisions actually improved. How much faster did delivery become? How much did approval times, defects or blockers drop? Even a before-and-after comparison would help.
I know these case studies are often written for prospective clients rather than PMs. A client reads it, likes the product and wants something similar. But clients can read between the lines too. No estimates, all communication through one person and changes to other teams’ systems all point to fairly specific risks for a client who’s paying attention.
There’s another commercial catch. Sell the absence of familiar management practices as a benefit and you may attract clients who later refuse to pay for planning, approvals or change control. The same team will then have to explain why all of that is suddenly necessary on their project. Lol.
If Daniil or his colleagues want to add some numbers or challenge my points, come find me. The answers may be there inside the project, or we might get to them in a private conversation. I didn’t find them in the published article.
By the way, on August 19, 2026, Daniil published a follow-up: “FMS a Year and a Half Later: From a Single Workflow to 52 Task Types, or How We Learned to Launch a New Task Type in 10 Minutes.”
Now this is more interesting. The author openly admits that, at the time of the first article, the app had only one fully functional workflow, and automated dispatching still hasn't been implemented. On the upside, there are now 52 task types, the workflow builder has reduced the setup time for a standard workflow from several weeks to just ten minutes, and they've introduced execution tracking and more detailed metrics.
Now that's a concrete result worth discussing. Still, it's hard to assess how effective the team's management approach actually was: the development cost savings from the workflow builder, total effort, and the impact of the approach on delivery quality remain undisclosed.
But credit where it's due: acknowledging the original limitations and showing measurable results deserves respect. That's exactly the kind of detail the first case study was missing.
I’m a project manager. About working with russian clients and teams, sharing experience and things I’ve noticed.