We Built the Software for an EV Cycle — Then Drove to IIT Jammu to Watch It Roll

There's a specific kind of quiet that happens right before a piece of software you wrote is supposed to move a real, physical object for the first time. No console. No localhost. Just a battery, a motor, a controller, and a few thousand lines of code that either work or don't. Last week I felt that quiet standing on the IIT Jammu campus, thumb hovering over a phone, about to unlock an EV cycle our team had been building the brain for.

We're a web shop. buildbyRaviRai builds websites, web apps, and dashboards out of Noida — that's the day job, and it pays the bills. So if you'd told 2021-me that we'd one day write the software that decides whether an electric cycle unlocks, how much battery it reports, and where it is on a map, I'd have assumed you'd mixed us up with somebody else. But that's the line of work we've been quietly drifting toward — first EV charging systems and OCPP, now the cycle itself. This is the honest behind-the-scenes of that build, and of the day the code finally rolled.

What a web team was even doing on an EV cycle

The instinct is to think "EV cycle" means hardware — motor, frame, battery pack, brakes. And it does. But in 2026, the part that actually differentiates one electric cycle from another isn't the metal. It's the software layer wrapped around the metal: can the rider unlock it from their phone, can the owner see battery health before it dies on the road, can a fleet operator find a cycle that's been left in the wrong place, can a service team get an alert before a cell fails instead of after.

None of that is mechanical engineering. It's app development, API design, real-time data, and a dashboard — which is precisely the work we do every week for clients who happen to sell something other than vehicles. The EV cycle just turned out to be a website's worth of problems wearing a helmet.

What we actually built

Stripped of jargon, the job had four pieces, and they're the same four pieces behind almost any connected product:

• The rider app. Unlock and lock the cycle, see remaining battery and estimated range, view ride history. The thing a normal person actually touches — and therefore the thing that has to feel instant, even when the network on a campus road doesn't.
• The firmware bridge. The small program living on the cycle's controller that listens for commands (unlock, lock) and reports back telemetry — battery voltage, speed, GPS position. This is where web habits go to die: there's no "refresh the page," no second chances if a packet drops on patchy 4G.
• The telemetry pipeline + dashboard. A backend that ingests the cycle's data and a web dashboard — our home turf — where an operator sees every cycle's battery, location, and status on one screen. This is just a CRM for objects that move.
• The battery layer. Reading the battery-management data and surfacing it honestly — not a green icon that lies, but real cell health, so a rider isn't stranded and an owner isn't surprised.

Ninety percent of that is work we've done before for screens. The other ten percent — the part where a wrong assumption doesn't throw an error but instead leaves a person standing next to a cycle that won't move — is the part you can't learn from a tutorial. You learn it by going to where the cycle is.

Why we had to actually go (you can't unit-test a road)

We had everything "working" in Noida. The app unlocked a simulated cycle. The dashboard showed beautiful fake telemetry. Every test was green. And every experienced builder reading this already knows what's coming: green tests on a simulator tell you almost nothing about a machine sitting in real weather, on a real network, with a real battery that doesn't behave like the spec sheet promised.

So we drove to IIT Jammu, where the cycle physically was, and where the people building the hardware side were. You can debug a web app from your desk forever. You cannot debug the half-second of doubt between tapping "unlock" and the lock actually clicking from a desk. You have to be standing there, watching a stranger's face, when it works — or when it doesn't.

Things the simulator never told us, that the campus did within the first hour: how the GPS drifts under a building, how much the battery reading swings between standing still and pulling away, how a command that's "fast enough" at a desk feels like a lifetime when you're holding a phone next to a cycle that hasn't moved yet. Every one of those was a small fix. None of them would have been caught without being there.

What IIT Jammu actually felt like

I'll be honest: the part I underestimated was the energy of the place. IIT Jammu is young as IITs go, and it has the particular kind of hunger that newer institutions have — people building real things, not just writing papers about them. Standing in a space where students and researchers were treating an electric cycle as a serious engineering problem reframed how I thought about our own little software contribution to it.

There's a humility that hits when your code is one layer in something many people built. The frame isn't yours. The battery chemistry isn't yours. The motor isn't yours. You wrote the part that makes it legible to a human with a phone — important, but one instrument in a band. For a team that usually owns the whole stack of a website end-to-end, being one contributor to a bigger physical thing was a genuinely good ego check.

What this means for where we're headed

We're not abandoning websites. The boring truth is that a connected EV cycle is mostly a website problem in disguise — auth, real-time data, a clean dashboard, an app a non-technical person can use without a manual. The skills transfer almost perfectly. What changes is the cost of being wrong: a bug on a marketing site is a typo someone might notice; a bug on a cycle is a person stranded on a road. That raises the bar on everything, and honestly it's made us better at the website work too.

If your company is putting software around a physical product — a vehicle, a charger, a machine, anything with sensors and a battery — the team that can build the app, the dashboard, and the bridge between them is rarer than you'd think, and it usually looks a lot like a good web team that's willing to leave its desk. That's the work we're increasingly saying yes to.

What the trip actually taught me

1. Green tests are a hypothesis, not a result. Until your code has moved the real thing, in the real place, on the real network, you don't know it works — you only suspect it.
2. Go to where the thing is. The most valuable bug reports of the whole project came from standing next to the cycle for one hour, not from weeks of remote testing.
3. The physical world doesn't throw exceptions. It just quietly does the wrong thing. Design your software to be honest about uncertainty — a battery icon that admits when it isn't sure beats one that confidently lies.
4. Being one layer in someone else's build is good for you. Owning the whole stack makes you precious about it. Contributing one well-made piece to a bigger thing teaches a different, more useful kind of discipline.
5. Web skills travel further than web people assume. Auth, APIs, real-time data and a clean dashboard are 80% of a connected hardware product. The other 20% you learn by showing up.

I drove back from IIT Jammu tired, a little sunburnt, and quietly thrilled in the way you only get when something you wrote made a physical object obey it. We build websites. But last week we also helped build something that rolls — and I'm not sure I've been that excited about shipping software in a long time.