Six projects.
Every decision
documented.

Architecture

Monolithic Next.js

Database

MongoDB Atlas

Media

Cloudinary CDN

Hosting

Vercel

The Problem

Most small hospitality businesses in India have no digital presence beyond a WhatsApp number. When pitching a web solution to these clients, telling them what their platform will look like isn't enough — they need to see it working, live, with real data they can touch. ReleaseRoom was built to be that proof of concept: a fully functional booking system that can be placed in front of any hotel owner during a pitch meeting and operated on the spot.

Why Next.js + MongoDB

The core requirement was a full-stack application with no third-party service bridging the frontend and backend — no separate Express server, no REST API scaffolding on a different host. Next.js App Router API routes + MongoDB with Mongoose gave us exactly that: one codebase, one deployment, zero friction. This combination is also battle-tested for database-driven applications at scale, making it the right choice for a client-facing product that needs to inspire confidence.

The Challenge — Storage

The first instinct was to store listing images directly on the server. That breaks immediately in a serverless environment like Vercel — there's no persistent file system. Rather than spinning up a dedicated storage bucket and adding infrastructure complexity, we offloaded all media to Cloudinary via URL references. Images are stored and served by Cloudinary's CDN; the database holds only the URL string. This kept the architecture lean and the hosting cost at zero, while still delivering fast image loads for end users.

What It Demonstrates

ReleaseRoom is the project we open on a laptop during a client pitch. It has a clean public-facing UI for browsing listings, a role-based admin dashboard with live data visualised through charts, real booking flows with status management, and a Cloudinary-powered media pipeline. A business owner can interact with it in under two minutes and understand immediately what their own platform would feel like. That is its primary function — and it does that job well.

Algorithm

Greedy debt minimisation

Updates

Real-time sync

Database

MongoDB Atlas

Hosting

Vercel

The Problem

Group outings — trips, dinners, events — always end the same way: someone overpaid, someone underpaid, and the reconciliation is a mess of messages and mental arithmetic. Apps like Splitwise solve this in Western markets but the experience for Indian users is clunky. SplitVibe was built to solve this cleanly: create a group, add expenses as they happen, and at the end know exactly who pays whom — and how few transactions it takes to make everyone whole.

The Algorithm

The core of SplitVibe is a debt-minimisation algorithm. Naively, if five people in a group all owe each other different amounts, you could have up to ten separate transactions. The algorithm reduces this to the theoretical minimum — typically two or three — by netting out balances, identifying who has a net positive balance (is owed money) and who has a net negative (owes money), and greedily matching the largest creditor with the largest debtor until all balances are zero. Implementing this correctly, especially handling floating-point precision across currency values, was the most technically demanding part of the build.

The Challenge — Live Groups

The second major challenge was making groups feel live. When one member adds an expense, every other member in that group should see the updated totals without refreshing the page. Getting real-time updates to work reliably across sessions — without a dedicated WebSocket server in a serverless environment — required careful thinking about polling strategy and state invalidation. The result is an experience that feels like a native app: changes propagate instantly, balances update in place, and the UI never feels stale.

Why It Matters

SplitVibe is the project that demonstrates algorithmic thinking, not just CRUD. Any developer can build a form that saves to a database. Fewer can build a system that takes a complex real-world problem — multi-party debt settlement — and solves it optimally. This project exists to show that gap.

Build Time

4–5 hours

API

RapidAPI

Storage

localStorage (30 days)

Auth

None required

The Problem

Reading long articles online is slow. Most summarisation tools are clunky, require sign-ups, or bury the summary in ads. Distill.Summr does one thing: paste a URL, choose how long you want the summary, get the answer in seconds. No account. No friction. History is stored locally for 30 days so your recent reads are always accessible.

The Real Purpose

This project was deliberate practice for a specific skill: integrating third-party APIs and building a clean product layer on top of infrastructure someone else built. In real-world development — and especially in AI-adjacent work — most of the interesting functionality is already built by someone else. The developer's job is to wire it up cleanly, handle edge cases, design the user experience, and ship fast. Distill.Summr was a simulation of exactly that workflow.

What Was Built

The RapidAPI summarisation endpoint handles the actual text extraction and compression. Everything else — the chat-style interface, URL validation, summary length controls, local storage history, error states, loading skeletons — was built from scratch. The frontend was designed to feel like a messaging app rather than a tool, which makes repeated use feel natural rather than transactional. Built start to finish in roughly four to five hours.

Frontend

React

Backend

Node.js + Express

Database

MongoDB

Hosting

Vercel + Render

Context

Twix Task was the first full-stack project built from scratch — React on the frontend, Node.js and Express on the backend, MongoDB as the database. The stack choice was deliberate: use the most established tools, understand how they connect, and don't abstract anything away. No Next.js monolith, no ORM. Just the raw pieces wired together manually so every layer is understood before moving to more efficient patterns.

What It Does

Users can create tasks, assign them a priority level (low, medium, high) and a status (todo, in progress, done), sort and filter across both dimensions, and see the distribution of their workload visualised in the dashboard. The interesting engineering question was not the CRUD operations — those are straightforward — but how to compute and display the task breakdown in a way that's actually useful at a glance. Thinking through that data model and visualisation layer was the core learning of the project.

What It Taught

Twix Task was the project that revealed the gap between knowing how to code and knowing how to build. Getting the data flowing between React state, the Express API, and MongoDB was technically simple. Deciding how to structure that data, what to expose via the API, how to keep the UI consistent with database state — those decisions don't have obvious answers. Making them here meant making them faster and better in every project that followed.

Client

Unisfera MUN

Stack

React + Firebase

Status

Live, still in use

Type

Client delivery

The Context

Unisfera is a student-run Model United Nations event spanning multiple schools. Before this platform, registration was handled through forms and spreadsheets — error-prone, hard to track, and not representative of the event's ambition. The brief was simple: build something students can sign up through, that Unisfera can manage on the backend, and that actually gets used.

The Stack

React and Firebase were the natural choices for a project that needed to ship fast and stay simple to maintain. Firebase handles authentication and the real-time database, which meant no backend server to maintain — the entire application runs on the client with Firebase as the data layer. For an event-based project with a defined lifespan and a non-technical operator, this was the right call over a heavier stack.

The Real Challenge — Design

The technical build was not the hard part. The hard part was design — and at the time, design instincts were still being developed. Some early choices looked off: spacing that felt cramped, font sizes that didn't breathe, colour decisions that didn't guide the user's eye. The project was delivered, used, and worked as intended. But looking back, the visual design choices were where the most growth has happened since. That gap is exactly what made every subsequent project look better — you can only learn what good looks like by shipping something imperfect first.

Cost

Zero per verification

Data sent

None — client-side only

Source

UIDAI offline XML

Use case

SMB KYC verification

The Problem

Businesses that need to verify a user's identity via Aadhaar typically rely on paid API services — each check costs money, and at scale that adds up. UIDAI provides an official offline verification path: users can download a signed XML file from the UIDAI portal that contains all their Aadhaar data. Most businesses don't know this exists, or don't have a clean way to parse and display it. TrackAadhaar solves this: upload the XML file, see all the data instantly, no API cost, no third-party dependency.

Why It Exists

This is a practical utility built for a real gap in the market. Startups and small businesses handling KYC — rental platforms, event organisers, service marketplaces — often can't justify the per-verification cost of paid Aadhaar APIs, especially in early stages. TrackAadhaar gives them a working alternative: offline XML parsing that runs entirely in the browser, meaning no user data is ever sent to a server. Privacy-preserving by architecture, not by policy.

Technical Approach

The UIDAI XML file is a structured document with a defined schema. Parsing it correctly — handling the nested data structure, extracting fields like name, DOB, address, and photo — required reading the UIDAI specification and building a parser that handles the format reliably. The UI surfaces all available fields in a clean layout, making it immediately readable without any technical knowledge on the operator's side.