I am writing this from Pathsala, a small town in the Barpeta district of Assam.
There is no WeWork here. No coffee shop with reliable Wi-Fi and a community Slack. No senior engineer you can tap on the shoulder. No startup culture, no VC ecosystem, no "tech scene" in any conventional sense.
What there is: a decent 4G connection (most of the time), documentation, and the particular stubbornness that develops when you have no other option but to figure things out yourself.
I want to write about what that actually means — not as a badge of hardship, but as a genuine description of the conditions that shaped how I work.
The Constraint That Became a Method
When you're learning to build software in a small town in Assam, you can't walk into a bootcamp or attend a hackathon. You read documentation. You read it carefully, because misreading it costs you hours you don't have. You build things that break, and you debug them alone, usually late at night.
This forces a discipline that I've come to believe is increasingly rare: understanding before acting.
I see the opposite pattern often in developer communities — the tendency to copy-paste, to ask before reading, to reach for a framework before understanding what it solves. That tendency is understandable when you're surrounded by people you can ask. When you're not, it's expensive.
The method I developed out of necessity — read the source, understand the constraint, design the solution, then implement — is now the deliberate core of how I work with clients. Not because it's the "principled" way. Because it's the only way that worked when I had no one else.
What I Actually Built Out Here
People sometimes assume that being in a place like Pathsala limits the quality of work you can do. I've found the opposite.
The distance from tech fashion is actually an advantage. I'm not chasing the framework of the month because no one around me is using it either. I choose technology because it's the right tool for the job — not because it's what the people at the conference are talking about.
The work I've done from here:
- Built and shipped a full non-profit ecosystem for MOSONiE Socio-Economic Foundation: React + Vike + Hono + PostgreSQL + Razorpay. In production, handling real donation flows.
- Delivered a Next.js + Gemini AI education portal for Aasha Foundation, serving the Bodoland community.
- Built the Namani Construction platform — interactive 3D model viewers, GSAP animations, NestJS backend — for a premium construction firm.
- Designed and deployed the Portfolio Nexus: a modular monolith API, Next.js SSG website, Vite admin dashboard, all self-hosted on VPS infrastructure I manage myself.
None of this required being in Bangalore or Mumbai. It required the discipline that comes from working in a place where there's no one to bail you out.
The NGO Work Is Personal
The organizations I've built for — MOSONiE, Aasha Foundation, others in progress — aren't just clients. They serve communities I grew up knowing.
North-East India is chronically underserved by quality web infrastructure. Most NGOs here are running on WordPress sites built years ago by whoever was available, maintained by no one, and increasingly insecure. Their digital presence doesn't reflect the importance of their work.
When I migrate one of these organizations from a bloated WordPress stack to a fast, maintainable Next.js platform, I'm not just doing technical work. I'm giving their volunteers time back. I'm reducing the fear that comes from "the website went down again." I'm making it easier for them to tell their story to funders and beneficiaries.
That's not a marketing statement. It's why I prioritize this work.
What Remote Actually Means for Quality
There's a prevailing assumption in the Indian tech industry that physical presence signals quality commitment. Video calls are considered inferior to in-person meetings. Remote developers are seen as harder to trust.
My experience is different. The clients I've worked with remotely have received more carefully documented systems, more thorough handover guides, and cleaner codebases than most onsite engagements produce — because remote work *forces* you to write things down.
When I can't explain something in person, I write an ADR (Architectural Decision Record). When I can't show someone a demo in real time, I write a clear deployment checklist. The documentation isn't an afterthought. It's how the work gets done.
Every project I ship includes:
- Full ADRs explaining why each major architectural decision was made
- Idempotent startup scripts (
./start.sh,./deploy.sh) that set up the entire environment from scratch - A structured README that a non-technical founder can actually follow
- Health check endpoints and monitoring configured out of the box
This is partly discipline. It's partly the North-East developer's survival mechanism: if you're not there to answer the question in person, you'd better have written the answer down already.
AATMANOVA and the Parallel Path
Alongside the software work, I also run AATMANOVA — a spiritual wellness studio offering Vedic numerology, Reiki healing, and energetic guidance. This is not a hobby. It's an active practice with real clients.
People who encounter both aspects of my work sometimes ask how they fit together. The short answer: they both come from the same root — a fascination with underlying systems.
Assam has a deep tradition of what might be called systems thinking, though it wasn't called that. Vedic frameworks map energetic patterns. Agricultural calendars map natural systems. The structure of Assamese classical music is governed by ragas — a codified system of emotional and temporal logic.
I grew up surrounded by these frameworks without consciously recognizing them as such. When I later encountered software architecture — domain boundaries, dependency graphs, modular design — it felt familiar. Different language, same fundamental project: finding the structure that makes complex things navigable.
A Note to Other Developers in Small Towns
If you're building software from a place that the tech industry doesn't consider a "hub," I want to say something directly: your location is not your limitation.
The infrastructure is a constraint. The distance from conferences and communities is a constraint. The absence of a local senior engineer you can learn from in person is a real disadvantage.
But the discipline you develop from working through those constraints — the careful reading, the self-reliance, the habit of documenting everything — is an advantage that people in the center of the scene often don't develop.
Build things. Document them. Ship them. The internet doesn't care where you're sending the commit from.
*If you're an NGO or small organization in North-East India looking for engineering support, reach out. I work with sliding-scale engagements for mission-driven organizations.*