The Yuvaraj Chronicle

Tagline

Every student’s GPA, without the spreadsheet.

The problem

Students across departments were working out GPA and CGPA by hand, or with generic online calculators that know nothing about PSNA’s credit structure. Each department carries different credit weights per regulation, so a generic tool quietly gives the wrong answer — and doing it manually invites arithmetic slips at exactly the moment the number matters most.

The goal

Give any PSNA student an accurate, department-correct GPA in under a minute, on a phone, with no login and no app install.

The solution

A department-aware calculator that loads the correct subject and credit table for the chosen department and semester, computes weighted GPA and cumulative CGPA, and includes a separate internal-mark calculator for mid-semester tracking.

My approach

I started by collecting the real credit tables department by department instead of assuming a uniform structure — that assumption is exactly what makes every generic calculator wrong here. Everything runs client-side so it loads instantly on a weak campus connection, and the form is shaped so the common path is three taps.

Key features

• Department-wise credit tables
• Weighted GPA per semester
• Cumulative CGPA across semesters
• Separate internal-mark calculator
• Works offline once loaded
• Mobile-first, no login

Tagline

A club that looks like it ships things.

The problem

UiZera, PSNA’s UiPath community club, had no home. Event details lived in WhatsApp forwards and printed posters, so anyone outside the immediate group had no way to find out what the club actually did or when anything was happening.

The goal

One public page that explains the club, shows the team, and lists events — clear enough that a first-year understands it in thirty seconds.

The solution

A responsive single-page site covering the club’s purpose, event history and team, designed and built end to end by me as the club’s Graphics Designer.

My approach

I designed it in Figma first, then built it. Doing both halves myself meant the visual identity and the markup never drifted apart — and it let me cut anything in the design that wasn’t worth the code it would cost.

Key features

• Club overview and mission
• Event listings and history
• Team section
• Fully responsive layout
• Static deploy, no backend

Tagline

An alarm you can’t switch off without facing the deadline.

The problem

Placement prep slips — not because students don’t care, but because the deadline is abstract. “Next year” creates no urgency at 6am, and DSA progress stays invisible when it’s scattered across notebooks, sites and half-remembered streaks.

The goal

Make the countdown impossible to ignore, and make progress visible enough to be worth continuing.

The solution

A Flutter app built around one confrontational idea: the morning alarm does not stop until you type how many days remain until your placement date. Around that sits a dashboard, a DSA tracker across 12 topics with company tags, task management with streaks, and a readiness score.

My approach

I designed the alarm mechanic first, because it’s the only genuinely novel part — everything else exists to support it. I also built it offline-first so it opens and works with no Firebase configured, which made testing on a real phone dramatically faster.

Key features

• Type-to-dismiss countdown alarm
• Placement countdown dashboard
• DSA tracker — 12 topics, company-tagged
• Task manager with streaks and history
• Readiness score and streak calendar
• Target company shortlist

Tagline

Blocking ads without reading your browsing history.

The problem

Manifest V2 blockers are being retired, and a lot of MV3 replacements either lost their teeth or kept broad host permissions that let them see every page you visit. I wanted to find out whether a capable blocker was actually possible inside MV3’s constraints, or whether everyone was just routing around them.

The goal

A working ad and tracker blocker built entirely on MV3’s declarative APIs — no permission to read your requests.

The solution

A blocker built on declarativeNetRequest, so filter rules are handed to the browser and enforced natively — the extension itself never sees your traffic. Cosmetic filtering then strips the empty containers left behind, and a popup gives per-site control.

My approach

I deliberately refused to fall back on blocking webRequest. That constraint is the experiment — the point was to learn what MV3 can and cannot do, which you don’t discover by working around it the moment it gets inconvenient.

Key features

• declarativeNetRequest rule engine
• Cosmetic filtering for leftover containers
• Per-site enable and disable
• Popup dashboard
• Options page with filter management
• Chrome 116+, Manifest V3

Tagline

Finding the businesses that don’t have a website yet.

The problem

Finding freelance leads by hand is slow and it goes stale — search Maps, open each listing, copy a phone number, check whether they already have a site, repeat. Hours of it, for a list that’s out of date by the time it’s finished.

The goal

Turn a Maps search into a structured CSV, including the one field that actually decides whether a lead is worth contacting: does this business have a website or not?

The solution

A Python tool that drives a headless Chrome session through Google Maps, waits for results to lazy-load, and extracts name, category, phone, address, rating, review count and website — flagging the businesses with no site. Exports straight to CSV, with a batch mode and a small local web UI.

My approach

I used a real browser rather than an API, because the data I wanted is rendered client-side. Most of the work went into waiting correctly — Maps loads results progressively, so naive scraping gets you the first six entries and a false sense of completeness.

Key features

• Headless Chrome automation
• Name, category, phone, address
• Rating and review count
• Website-presence flag
• CSV export
• Batch mode across queries
• Local web interface

Tagline

My first paid product, end to end.

The problem

A client needed a working commerce presence — a storefront, a real payment path, and some way to manage it all without touching code or calling me every time a price changed.

The goal

Ship a complete product with working payments and an admin console the client can genuinely operate alone.

The solution

A customer-facing storefront with a separate admin console, Firebase for auth and data, Razorpay for payments, deployed on Netlify.

My approach

I split the admin into its own application instead of hiding routes behind a role flag. It’s a clearer security boundary, and it let me deploy and iterate on each side independently. Firestore rules do the actual enforcement — the UI just reflects them.

Key features

• Customer storefront
• Separate admin console
• Firebase auth and Firestore
• Razorpay payment integration
• Environment-based configuration
• Netlify deployment

Tagline

Appointments, without the phone call.

The problem

A clinic was running appointments on phone calls and paper. That means double bookings, no record of who cancelled, and staff spending the whole morning on the phone instead of with patients.

The goal

Let patients book a real slot themselves, and give clinic staff one screen that shows the day.

The solution

A booking platform with a patient-facing flow and an admin dashboard for staff to manage doctors, slots and appointment states.

My approach

I modelled the slot as the unit of truth rather than the appointment. That makes double-booking structurally impossible instead of something you validate against afterwards and hope you caught.

Key features

• Patient booking flow
• Admin dashboard for clinic staff
• Doctor and slot management
• Appointment state tracking
• Firebase-backed data
• Vite for fast iteration

Tagline

An afternoon of manual emails, reduced to one command.

The problem

After results are published, someone has to send every student their individual GPA breakdown. By hand that means opening a spreadsheet, copying a row, pasting it into an email, checking the address, and repeating a few hundred times — with a real chance of sending the wrong person someone else’s marks.

The goal

One command that reads the sheet and sends every student their own breakdown, correctly, every time.

The solution

A Node script that parses the results spreadsheet, builds a per-student message, and sends it through Gmail using Nodemailer and the Google APIs — with credentials kept in environment variables rather than the source.

My approach

I treated the spreadsheet as untrusted input, because it is. Hand-maintained sheets carry blank rows, stray whitespace and duplicated headers. When the failure mode is emailing someone else’s marks, validating before sending matters far more than the sending does.

Key features

• XLSX parsing
• Per-student message generation
• Gmail delivery via Google APIs
• Environment-based credentials
• Dry-run before live send

Tagline

Every student sees their own work, and only their own.

The problem

Department assignments and deadlines were tracked in group chats — which means no history, no accountability, and no reliable way for a student to see what is actually due.

The goal

A tracker with a student view and an admin side, where students structurally cannot read each other’s records.

The solution

A Firestore-backed task tracker with separate student and admin surfaces, where access is enforced in security rules rather than in the interface.

My approach

I wrote the Firestore rules first and built the UI against them. If the rules are the real boundary, they’re what you should design around — hiding a button is not security, it’s decoration.

Key features

• Student task view
• Admin management side
• Firestore security rules
• Per-student data isolation
• Task history

Tagline

Reading an interface closely enough to rebuild it.

The problem

I could tell good mobile commerce UI from bad, but I couldn’t explain why. An opinion you can’t justify isn’t a skill — it’s a preference.

The goal

Rebuild a dense, real e-commerce interface piece by piece until the decisions behind it become visible.

The solution

A full Figma reconstruction of the Shopsy app — navigation patterns, product card hierarchy, and how a dense catalogue stays scannable on a small screen.

My approach

I rebuilt it rather than referenced it. Copying a layout forces you to notice every spacing decision, every step in the type scale, and every place the original breaks its own grid deliberately — none of which you see by looking.

Key features

• Navigation pattern study
• Product card hierarchy
• Dense catalogue layout
• Component structure
• Mobile-first grid