The lead developer behind the scheduling platform now embedded in Ford’s US mobile app explains what it took to unify 600 independent dealerships onto a single system — and what breaks when enterprise software meets real-world resistance
Gartner projects that global IT spending will cross $6 trillion in 2026 for the first time, a 9.8% jump year over year, with enterprise software growing faster than any other category. Yet the rate at which organisations actually adopt the tools they purchase has not kept pace: building a solid platform is one problem, persuading hundreds of separate locations with their own workflows, staff, and legacy habits to operate inside a single system is a fundamentally different one. Abhiram Madugula, a software engineer with a Master’s in Applied Computer Science and close to a decade of shipping production IT systems, confronted that disconnect directly at Saanvi Technologies when he led the development of a unified scheduling platform for Ford’s US dealership network. Today, upwards of 600 service locations run their daily operations on that software, its scheduling APIs feed directly into Ford’s own consumer mobile app, and a 2026-2027 expansion targeting 918 additional dealerships is already underway. On April 11, the International Cases&Faces Award recognised Madugula’s work with an Achievement in Engineering prize in the Cloud Computing category. We asked Madugula what the implementation process looked like from the inside, what technical and organisational obstacles came closest to derailing it, and what he has learned about creating enterprise software that survives contact with the people who are supposed to use it.
Abhiram, your platform now handles daily scheduling for upwards of 600 Ford service locations across the US. Before it existed, each dealership ran its own independent process. What was breaking at scale under the old model?
There was no shared system connecting them. Every location ran its own process independently, and none of those processes talked to each other. Once the number of vehicles on the road climbs quickly, that fragmentation creates operational inefficiencies at every level. Our answer was a single web-based platform built on React.js that could unify how appointments get booked, reduce the upkeep burden on each individual location, and still adapt to whatever dealer management software a given store already runs. Dealers set up their side, customers book from theirs, and a single architecture handles both.
Enterprise software adoption rates are notoriously low, and most internally deployed tools get quietly abandoned within the first year. Your platform crossed 500 active locations and kept climbing. What in the rollout process prevented that drop-off?
We designed for variation from the start. No two stores look alike — each one has its own service hours, its own bay setup, its own internal workflows, and none of those details are interchangeable. A system that only fits one configuration would have collapsed at the second location, so the core logic stays standardized for everyone, while each dealer configures what matters to them: time-slot rules, bay counts, compatibility with whichever management software they already own. Maintaining that consistency across such a large codebase requires discipline – I run cross-team architectural reviews to make sure that every new feature or integration aligns with the platform’s core design, which has been a major factor in keeping the system stable as it scales. On the rollout side, we deliberately avoided pushing large batches of locations live at once. Each dealership had to be fully operational and adopted before we moved to the next. What drives long-term stickiness, though, is practical daily value. Once the platform covers availability tracking, capacity management, and routine workflows in a single place, nobody volunteers to go back to juggling three separate tools.
Ford integrated your scheduling APIs directly into their consumer-facing mobile app, so your infrastructure now sits between the customer and the dealership at the moment of booking. What does the API layer actually handle in real time when a vehicle owner confirms an appointment?
From a customer’s perspective, it is straightforward – you open the Ford app, find a nearby dealer, choose an available time slot, and confirm. What runs underneath is more involved; our system checks that dealer’s service availability, accounts for capacity and existing bookings, and either confirms or proposes an alternative. All of that has to work smoothly across hundreds of dealer setups that each carry their own parameters. The whole point was to let car owners handle everything inside one app rather than navigating an outside portal, and the APIs we developed were engineered specifically to plug into Ford’s consumer-facing mobile environment without adding extra steps.
That real-time coordination across hundreds of different dealer configurations gets substantially harder during peak periods, when both staff and consumers are hitting the system simultaneously. A slowdown of even a few minutes can cascade into thousands of missed appointments. What does your triage process look like when something starts degrading, and how narrow is the window before it costs real bookings?
Performance challenges are easily the hardest category of work we deal with, because the margin for error is essentially zero. When something slows down, you need to isolate the root cause and deliver the best solution before the ripple effects spread – every dealership in the network is counting on uninterrupted access. Triage discipline is constant: pinpoint the bottleneck, fix it, confirm the fix holds. At the scale of 600-plus locations, a few minutes of degraded response time can translate into a massive number of lost appointments nationwide, and once service customers lose confidence in a booking tool, getting them back is far harder than keeping them in the first place.
The Cases&Faces Award just recognised your platform with an Achievement in Engineering prize in the Cloud Computing category, and your 2026–2027 roadmap calls for 918 additional dealerships and a full Xtime integration. With that kind of external validation and an expansion that more than doubles the current footprint, how are you structuring the next phase so that new locations actually stay on the platform?
The Cases&Faces recognition is meaningful because the jury evaluated the platform’s cloud-native architecture and real-world scale, not just the concept behind it. That kind of independent validation reinforces the approach we have taken from the start. As for the expansion, the principle stays the same: never trade adoption depth for rollout speed. Pushing a large number of locations live in a short window might look good on a progress report, but if half of those stores quietly revert to their previous habits within weeks, the numbers mean nothing. Our objective is quality-driven onboarding; each dealership must fully adopt and effectively use the platform before we move on to the next. That approach minimizes operational friction and ensures consistent customer experiences across very different dealership environments. For the Xtime expansion specifically, we are merging scheduling logic and store-level settings into one continuous workflow instead of layering separate products on top of each other. Technically, it is a heavier lift, but the outcome is a single coherent experience for both dealers and their customers.
Your code runs inside a Fortune 500 consumer app, and the next phase takes it past 1,500 locations. For engineers who want to build at that scale, what do you know now that you could not have learned in a lower-stakes environment?
Never stop upgrading what you know. Requirements shift, frameworks evolve, certifications that carried weight three years ago may be obsolete tomorrow – standing still is the quickest way to fall behind. Beyond the technical side, get comfortable operating under pressure. Resolving a critical latency issue while hundreds of live locations depend on your code feels nothing like debugging in a sandbox. And before you write a single line, spend time understanding the workflows your software is supposed to serve. A surprising number of problems that appear technical are really process gaps that the right code can address cleanly. If you design tools around how people already operate instead of forcing them to relearn everything, adoption takes care of itself.
