Lessons from a Military Kid Who Became a Builder
Ten cities across India and the US by age 23. Growing up in an army family teaches you things that no MBA curriculum covers — here's how those lessons shaped how I build products today.
You Learn to Start Fresh
By the time I was eighteen, I had lived in eight cities. Every two or three years, my father's posting would change, and we'd pack up and relocate — Bangalore to Lucknow, Lucknow to Ambala, Ambala to Delhi, and back and forth again.
Most people describe this as difficult. It wasn't easy. But what it gave me was a specific kind of muscle: the ability to start fresh without treating it as a crisis.
When you move cities repeatedly as a child, you learn that the social infrastructure you thought was permanent is actually just a temporary arrangement you built through consistent small actions. And if you built it once, you can build it again. The loss of continuity is real. But so is the realization that you're more capable of rebuilding than you thought.
I think about this a lot when I'm starting a new project. There's a phase in every build where the foundation isn't there yet — no users, no validation, no certainty. Most people treat this as uniquely uncomfortable. I've started to treat it as just the beginning of a familiar process. You figure out the local terrain, you make the first few connections, and things start to cohere.
Structure Is a Tool, Not a Prison
Army cantonment life is structured to an almost absurd degree. Mealtimes, bed times, the layout of the housing colony, the hierarchy of interactions — everything has a form. Growing up inside that structure, you could either resent it or learn from it.
I learned from it. Specifically, I learned that structure creates freedom. When the mundane decisions are already made — when you know what time you're eating, where you're sleeping, what the rules are — your cognitive energy gets freed up for the things that actually matter.
This shows up in how I build. I'm not a spontaneous coder. I plan before I type. I write down what I'm trying to accomplish before I open the IDE. I batch similar tasks together. I have routines for the unglamorous parts of product development — writing tests, handling edge cases, thinking through error states — because I don't want to have to decide whether to do them. They're just part of the process.
The army taught me that discipline isn't about restriction. It's about creating the conditions for consistent output regardless of mood or motivation.
Adaptability Is Different from Flexibility
One thing I want to distinguish: adaptability is not the same as flexibility. Flexibility means you bend easily. Adaptability means you change what you need to change while keeping what matters intact.
Military families adapt constantly. New city, new school, new social dynamics, new expectations. But the things that stay constant — family, values, work ethic — stay extremely constant. The adaptation is surgical, not wholesale.
I've tried to bring this to product development. When I'm iterating on something that isn't working, I try to be specific about what isn't working rather than throwing the whole thing out. Is it the positioning, the UX, the core mechanic, or just the copy? Adaptability means changing the right thing, not everything.
What the Indian Army R&D Experience Actually Taught Me
After finishing my B.Tech, I spent about a year working on software projects for Indian Army R&D. The two major projects were a Military Minefield Database System — an Android app for land mine planning and demining — and a multi-hop ad-hoc mesh network for battlefield communication.
Both of these projects had constraints I'd never encountered in academic or startup contexts. The software had to work in environments with no internet connectivity, on hardware that couldn't be upgraded, under conditions where failure had consequences that weren't just a bad quarter.
What I learned was that reliability is a design choice, not an afterthought. You don't add reliability at the end. You design for it from the start. What happens when the GPS signal drops? What happens when the device battery dies mid-mission? What happens when the operator is under stress and makes an input error?
Every product I've built since has been shaped by that framing. I think about failure states early. I think about what happens when the thing I depend on isn't there. I think about the user who is doing something stressful and doesn't have time to read an error message.
It's a different way of thinking about software than you get from building for well-connected users in comfortable environments.
On Building in Multiple Contexts Simultaneously
I work full-time as an Application Developer at ADP. I'm building Stak, BetWise, and an AI investment platform on the side. I document what I'm learning publicly.
A lot of people ask how I manage all of it. The honest answer is that it comes back to the military-kid thing: I'm not alarmed by context-switching. I've been doing it my whole life. Jersey City to Des Moines to Syracuse to Bangalore — I can hold multiple contexts without losing the thread.
The risk, and this is something I actively watch for, is shallow engagement across too many things. The goal isn't to be busy. The goal is to be building things that compound — skills, audiences, products, relationships — so that each context makes the others stronger rather than diluting all of them.
I haven't fully figured that out. But I think the framing itself is the right one: not "how do I do more things" but "how do I do things that reinforce each other."