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.
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.