Three projects, three different problems
I get asked fairly often which project I'm most proud of, and the honest answer depends on what you're asking about — technical depth, real-world impact, or just the cleanest piece of engineering. So instead of picking one, here's a walkthrough of the three projects that make up my current portfolio, what each one actually demanded of me, and why I built each one the way I did.
KisanX — the flagship
KisanX is the project I'd point to first. It's a direct-to-consumer marketplace connecting Indian farmers with customers, and I co-founded and built it across two full development phases: a PHP and MySQL web application first, then a complete MERN-stack and React Native rebuild with JWT authentication, OTP verification, and a Render-hosted backend.
What makes KisanX the flagship isn't just the tech stack — plenty of student projects use MERN. It's that the project solves an actual problem, went through a real architectural pivot when requirements changed (web-only to web-plus-mobile), and was good enough to be selected at the Avishkar Inter-Collegiate Research Convention, University of Mumbai, in the Agriculture & Animal Husbandry category. I've written the full technical breakdown on the project page, and the story of the rebuild itself on the blog.
What makes KisanX the flagship isn't just the tech stack — plenty of student projects use MERN. It's that the project solves an actual problem, went through a real architectural pivot when requirements changed (web-only to web-plus-mobile), and was good enough to be selected at the Avishkar Inter-Collegiate Research Convention, University of Mumbai, in the Agriculture & Animal Husbandry category. I've written the full technical breakdown on the project page, and the story of the rebuild itself on the blog.
The part I keep coming back to, almost a year on, is how much the second phase changed my understanding of what "finished" means for a piece of software. The PHP version felt finished when it worked. The MERN and React Native version forced me to think about things the first version never demanded — token expiry, OTP delivery failures, what happens to a cart if a network request silently fails on a mobile connection. Those are the kinds of edge cases you only really learn to care about once real users, even a small group of them in a research demo, start interacting with something you built.
The Capital Home — knowing when not to over-engineer
The Capital Home is a real-estate website, and on paper it's the "simplest" project in my portfolio — plain HTML, CSS, and JavaScript, no framework, no backend. I think that simplicity is exactly why it belongs in this list. The client needed a fast, professional, mobile-first landing page, not a content management system they'd have to maintain. Reaching for React or a CMS here would have added complexity that didn't serve the actual brief.
This project taught me something that doesn't get said enough in developer portfolios: knowing when *not* to use a framework is a skill, not a gap. A static site that loads instantly and never needs a dependency update is sometimes the more impressive engineering decision than a more "advanced" stack would have been.
Vastu Properties — React where it actually earns its place
Vastu Properties sits at the opposite end of that spectrum, and deliberately so. It's also a real-estate platform, but with a growing list of property listings that needed filtering, so I rebuilt it in React.js with a proper component architecture and dynamic content rendering. The contrast with The Capital Home is the point: same industry, similar brief on the surface, but a genuinely different technical need underneath, which led to a genuinely different stack.
Building these two real-estate sites back to back was a useful exercise in not defaulting to "my favourite stack" for every job. React solved a real problem for Vastu Properties — client-side filtering and a component model that scales with inventory — in a way it wouldn't have for The Capital Home's much simpler, largely static brief.
Building these two real-estate sites back to back was a useful exercise in not defaulting to "my favourite stack" for every job. React solved a real problem for Vastu Properties — client-side filtering and a component model that scales with inventory — in a way it wouldn't have for The Capital Home's much simpler, largely static brief.
It also meant learning to ask better questions before writing any code. With Vastu Properties, the number of listings the client expected to manage, and how often they'd change, directly informed whether filtering needed to happen client-side (which is what I built) or would eventually need a real backend and search index. For now, client-side filtering in React was more than enough, but it's the kind of decision I'd revisit if the property count grew by an order of magnitude.
The common thread across all three
Looking at KisanX, The Capital Home, and Vastu Properties side by side, the common thread isn't a shared technology — it's a shared habit of matching the stack to the actual constraint, rather than to convention. KisanX needed a mobile client, so it needed an API-first MERN architecture and JWT auth. The Capital Home needed speed and zero maintenance, so it stayed static. Vastu Properties needed dynamic filtering at scale, so it became a React app.
I also tried to carry security thinking across all of them where it was relevant — password hashing and session handling in the PHP-based work, JWT and OTP verification in the MERN/React Native work — partly shaped by the Python for Cyber Security course and Deloitte Cybersecurity Job Simulation I completed alongside building these projects.
I also tried to carry security thinking across all of them where it was relevant — password hashing and session handling in the PHP-based work, JWT and OTP verification in the MERN/React Native work — partly shaped by the Python for Cyber Security course and Deloitte Cybersecurity Job Simulation I completed alongside building these projects.
There's a smaller, less visible thread too: every one of these projects forced me to get comfortable being the only person responsible for the whole stack. There was no separate backend team to hand the database design to, no dedicated DevOps person to figure out deployment. On KisanX that meant designing the MongoDB schema, building the Express API, writing the React Native screens, and setting up the Render deployment myself, end to end. On the two real-estate sites it meant being both the developer and, informally, the person making product decisions about what the client actually needed versus what they initially asked for. That full-stack-in-the-literal-sense experience is, I think, the most transferable skill across all three projects — more than any individual technology.
What's next
KisanX is still the project I expect to keep iterating on — there's more to do on the dashboard experience and on hardening the API further. Beyond that, I'm looking for an internship or entry-level role where I can apply these same instincts — picking the right tool for the actual constraint, not the trendiest one — inside a real engineering team. If that's something you're hiring for, my contact page has every way to reach me.