SELECTED WORK

The evidence.

Four projects, read the way a reviewer would read them — the problem, what I actually built, the stack, what it taught me, and the limitation it still carries. One of them is live and serving a real business. Nothing is described as more finished than it is.

4 cases 1 in production 2 solo builds 2 open-source contributions
CASE 01 / 04

Rinky Commerce Engine

Designed, built and deployed a live commerce platform for a jewellery business in Kanpur — backend, database, auth and frontend.

In production Solo build Full-stack
Problem

Rinky Jewellers had no digital storefront and no way to manage a catalogue without editing files by hand. They needed a real shop customers could browse, and an admin surface the owner could use without a developer sitting next to them — running cheaply enough to be worth keeping online.

What I built
  • A REST API on Node.js and Express, with routes split by concern — auth, products, wishlist, contact, admin — and authorisation applied at the router level rather than per handler.
  • Session-based authentication with bcrypt hashing at 12 salt rounds, HTTP-only SameSite cookies, and sessions persisted in MongoDB through connect-mongo so they survive a restart and can be invalidated centrally.
  • Mongoose schemas for users, products, orders and contact messages on MongoDB Atlas, including jewellery-specific fields such as BIS hallmark metadata.
  • Role-based admin APIs for product CRUD, featured-product management, user administration, contact messages and platform stats.
  • Email verification and password recovery through the Brevo transactional email API, with links built from a configured production base URL.
  • Helmet and IP-based rate limiting on credential endpoints, plus a /healthz check that returns 503 when MongoDB is unreachable.
  • A responsive storefront in plain HTML, CSS and vanilla JavaScript — no framework and no build step — with shared behaviour factored into reusable modules.
  • Production deployment on Render with proxy-aware Express config, secure cookies, and secrets kept in the environment rather than the repository.
Stack
Node.js 18+ Express 4 MongoDB Atlas Mongoose 8 express-session connect-mongo bcryptjs Helmet express-rate-limit Brevo API Render Vanilla JS
Decisions
  • Server-side sessions over JWTs — session state stays centrally managed and can be invalidated without handing an auth token to client-side JavaScript.
  • No frontend framework — a catalogue site does not need a build pipeline, and skipping one kept the client light and the deployment simple.
  • MongoDB — a document model fits a catalogue whose products carry uneven, category-specific attributes.
What I learned

What changes when the thing is actually live: environment-based configuration, proxy-aware cookie settings, health checks that tell you which dependency died, and the difference between code that passes on my machine and code someone else's business depends on.

Limitation

Cart, checkout and payment processing are not implemented. The Order model and the Razorpay dependency in the manifest are planned infrastructure, not working features, and should not be read as production functionality. Content Security Policy is currently disabled because the frontend still relies on inline scripts and styles — tightening that means moving them to approved external assets or nonce-based execution first.

Live site ↗ Source is private — happy to walk through it on request
CASE 02 / 04

Facial Attendance System

Built a local face-recognition check-in logger using OpenCV and scikit-learn.

Solo build Python & ML
Problem

Logging student check-ins by hand is slow and easy to get wrong. This project explores whether a local webcam feed can recognise faces and write the attendance log itself — entirely on-device, with no service to sign up for.

What I built
  • Face detection with OpenCV Haar Cascade classifiers, cropping face bounds out of a live video stream and normalising them to a fixed 50×50 resolution.
  • A local K-Nearest Neighbors classifier in scikit-learn, trained on pre-captured face vectors to identify a known user from the stream.
  • A CSV logger that records the recognised name and the check-in timestamp using Python's built-in CSV writer.
  • A Streamlit dashboard that reads the log and displays classroom check-ins in real time.
Stack
Python OpenCV Scikit-learn Streamlit Pickle CSV
What I learned

The fundamentals underneath a classifier, in order: camera frame capture, image preprocessing, feature extraction, and training a simple classification algorithm on the result. Also that most of the work in an ML project is not the model.

Limitation

The system classifies faces from a webcam stream against pickle-serialised training data. It has no depth check or 3D liveness detection, which means a flat photograph will defeat it. Privacy and consent safeguards would be required before any real deployment — this is built for learning and local demonstration.

CASE 03 / 04

AdityaNet

Contributor to an open, verifiable solar-flare research platform for Aditya-L1 satellite data.

Open source Contributor Research
Problem

Solar-flare detection benchmarks and Level-1 dataset derivation for the Aditya-L1 satellite's SoLEXS and HEL1OS instruments needed an open, reproducible, verifiable engineering platform — one where published dataset outputs can be inspected and rebuilt rather than taken on trust.

What I contributed
  • Code contributions to the research verification platform and its Astro web interfaces.
  • Helped configure automated verification check budgets, type-safety testing under Astro, and responsive UI components.
  • Collaborated on documenting reproducibility protocols for Level-1 solar data ingestion and byte-identical local rebuild checks.
Stack
Python Astro Three.js React Tailwind CSS TypeScript Vitest
What I learned

Build-time budget enforcement, what structured scientific reproducibility protocols actually require of a codebase, and collaborative git development on an open-science project with other contributors.

Scope of contribution

This is a collaborative open-source research platform, not my project. My contributions were to parts of the codebase, the verification setup, and the documentation — not to the principal solar-flare research or its algorithms.

CASE 04 / 04

ASTRA

Contributor to an automated stellar transient recognition and classification platform.

Open source Contributor Research
Problem

Stellar transient classification needs open, reproducible computation benchmarks — server-side model inference that can be re-run, and time-series visualisations dense enough to show what the classifier is actually reacting to.

What I contributed
  • Helped configure server-side model inference with ONNX Runtime Node inside the transient recognition app.
  • Built parts of the interactive 3D WebGL space-mapping visualisations using Three.js and React Three Fiber.
  • Collaborated on dense time-series astronomical chart components with Recharts.
Stack
Next.js React Three.js ONNX Runtime Node TypeScript Recharts Lenis
What I learned

Server-side model loading, 3D WebGL camera setup, dynamic chart scaling for data that varies by orders of magnitude, and working inside someone else's architecture without breaking it.

Scope of contribution

A collaborative research platform. My work was on the front-end space visualisations, the server-side inference configuration, and the charting UI — not the core transient classification algorithm design.

05 / TOOLING

Everything below has been used inside one of those four.

No aspirational entries. If it is on this list, it shipped in a project above.

Languages

Python TypeScript JavaScript HTML/CSS SQL

Backend & data

Node.js Express REST APIs MongoDB Atlas Mongoose Session auth bcrypt Helmet Rate limiting SQL

Libraries & frameworks

Next.js React Astro Three.js ONNX Runtime Streamlit Scikit-learn OpenCV Recharts

Tools & environments

Git & GitHub Render Vitest Tailwind CSS npm / pnpm Linux CLI