Portfolio

SHREESH PATIL

COMPUTER ENGINEER / UI-UX / SYSTEM DESIGN

Building scalable systems and brutalist UX for real-world impact.

About

Computer engineer focused on systems, security, and UX.

I design clean, structured digital experiences.

Systems-first thinking

Security-focused design

Performance-aware engineering

Projects

UX CASE STUDY — ERP REDESIGN

ERP UI/UX Redesign

ERP UI/UX REDESIGN

Problem

The existing university ERP portal was desktop-only, visually inconsistent, and required students to navigate 4–6 screens to access basic information like attendance, fees, or today's schedule. No unified design language existed across modules — each section felt like a separate product.

Students needed to switch between three disconnected modules — academics, accounts, and examination — each with its own login flow, navigation pattern, and visual language. Core daily tasks like checking attendance or viewing fee dues required multiple redirects and re-authentication steps, creating unnecessary friction for routine use.

The information hierarchy within each module was inconsistent. Primary actions competed visually with secondary ones, and dense data tables were presented without summarisation or prioritisation. There was no mobile-responsive layout, making the system difficult to use on smartphones — the primary device for most students. Duplicated workflows across modules (e.g., separate fee views in both the accounts and examination portals) added confusion without adding value.

Fragmented access across attendance, academic records, fee payments, results, and timetables

Inconsistent navigation patterns — each module behaved like a standalone application

No mobile-first experience; the portal was unusable on smaller screens

Poor information hierarchy with data-heavy pages and no clear visual priority

Duplicated workflows forcing students to re-enter the same context in multiple places

Repeated login prompts and session timeouts disrupting daily usage

4–6 taps

to reach any key info

0 mobile screens

in the original system

3 separate codebases

for academics, accounts & results

Approach

One system. One language. One tap to anything.

The redesign unified all ERP modules under a single mobile-first interface built around the student's daily flow — login once, see everything relevant on the dashboard, drill into any module in one tap. A shared component library (cards, list rows, status chips) creates visual consistency across academics, accounts, and results.

The process began with a full interface audit of the existing system — cataloguing every screen, navigation pattern, and interaction. This was followed by an information architecture review to understand how data was structured and surfaced across modules. Workflow mapping helped identify where students encountered the most friction, and a component inventory revealed the extent of visual inconsistency between sections.

01

Audit all existing screens for information hierarchy and navigation patterns

02

Review information architecture and identify redundant or fragmented workflows

03

Map student task flows for the five most common daily interactions

04

Build a component inventory and define a unified design token set

05

Redesign each module as a card-based, scrollable mobile view

06

Introduce a persistent bottom nav for zero-cost navigation

07

Validate with student walkthroughs on 5 core tasks

A unified design system was created to replace the ad hoc styling that had accumulated across modules. Defining a single token set — one primary colour, a consistent type scale, and standardised spacing units — meant every new screen could be built from the same foundation, reducing design debt and ensuring visual coherence without additional effort per module.

Card-based layouts were chosen because they map naturally to the way students scan academic information: one card per subject, one card per fee item, one card per notice. Mobile-first navigation was prioritised to reduce the number of taps required for routine tasks. The goal was to make attendance, timetable, and fee status reachable within two interactions from the home screen, matching the mental model students already had from consumer apps.

Design Journey

Discovery & Audit

The process started with a structured review of the existing ERP portal. Every screen was catalogued — login flows, module landing pages, data tables, and settings panels. The goal was to understand what the system was actually asking students to do, not what it was designed to do in theory.

The audit revealed that the portal had grown organically over time, with each module developed independently. Navigation labels were inconsistent, iconography varied between sections, and the same action (e.g., viewing a fee receipt) was accessible through different paths depending on which module the student entered from.

User Pain Points

Walkthrough-based evaluations with students identified that attendance, timetable, fees, and results were the four most frequently accessed sections — yet none were reachable from a single consolidated view. Students routinely opened multiple browser tabs or logged into the portal two to three times per session to complete tasks that should have been a single flow.

Scenario testing surfaced a consistent pattern: students preferred dashboard-based navigation where key information was summarised upfront, rather than navigating through module-level menus to locate data. The existing module-based structure forced users to know where information was stored rather than letting the interface surface it contextually. Repeated login prompts and unclear session states added to the cognitive load.

Information Architecture

The existing system was structured around administrative modules — Academics, Accounts, Examination — which reflected the backend organisation but not the student's mental model. The redesign reorganised content around tasks and frequency of access. High-priority items (today's timetable, pending fees, recent results) were elevated to the dashboard level. Lower-frequency items were moved one level deeper.

Navigation depth was reduced by collapsing redundant intermediate screens. In the original system, viewing a subject's attendance required three navigations: module selection, academic year selection, then subject selection. The redesigned flow surfaced attendance by subject directly from the dashboard, reachable in one tap. Most daily tasks were brought within two interactions from the home screen.

Design System

A minimal design system was established before any screen was redesigned. The token set included a single blue primary colour for interactive elements, a neutral gray scale for backgrounds and borders, and a two-weight type scale (regular and bold) to enforce hierarchy without introducing visual noise. Spacing was standardised to an 8px base grid, ensuring consistent density across all screens.

The component set was deliberately small: a card container, a list row, a status chip (Pending / Active / Completed), a section header, and a bottom navigation bar. Keeping the component count low reduced decision fatigue during design and made implementation more predictable. Every screen in the redesign is composed from this set, ensuring visual coherence without requiring per-screen design decisions.

Wireframing

Low-fidelity wireframes were created for the six primary screens: login, home, dashboard, results, account summary, and timetable. Each wireframe focused on layout and content priority rather than visual design, making it easier to evaluate the information hierarchy in isolation before applying colour and typography.

The wireframing phase surfaced several layout decisions that were carried into the final design: the identity card at the top of the home screen to confirm the logged-in context, the tab row on the results screen to avoid deep scrolling, and the toggle filter on the account summary to separate pending and paid items without requiring a separate screen.

Prototype Validation

Task-oriented reviews were conducted using a click-through prototype covering five common student tasks: checking today's timetable, viewing attendance for a specific subject, checking fee dues, looking up a recent test result, and finding the notice board. These scenarios were chosen because they represented the highest-frequency use cases identified during the audit.

Feedback sessions with students highlighted a few navigation adjustments — most notably, making the bottom navigation labels more descriptive and ensuring the dashboard scroll didn't bury critical information below the fold on smaller screen sizes. Both were addressed in the final screens. The overall response confirmed that the unified dashboard approach significantly reduced the time required to locate information compared to the original module-based structure.

Design Decisions

Persistent Bottom Navigation

A fixed bottom navigation bar keeps the four primary sections — Home, Academics, Accounts, and Examination — always accessible without requiring the student to navigate back to a root screen. This eliminates a full navigation layer and ensures orientation is always clear, regardless of how deep into a module the user has gone.

Unified Dashboard

Rather than routing students through a module selector on every session, the dashboard surfaces the most relevant information upfront: today's schedule, attendance status, pending fees, and recent results. This matches the way students actually use the system — checking a few key things quickly — rather than forcing a deliberate navigation decision each time.

Standardised Card Components

All data — whether a subject entry, a fee line item, or an assignment row — is displayed using the same card container. This means students only need to learn one interaction pattern. Cards are scannable, support consistent status indicators, and adapt well to varying content lengths without breaking the layout.

Consistent Spacing System

An 8px base grid was applied across all screens to create a predictable visual rhythm. Consistent spacing reduces the cognitive effort of parsing a new screen, because the eye learns to expect where content will be positioned. It also prevented the density issues present in the original design, where data was packed without breathing room.

Shared Status Indicators

Status chips — Pending, Active, Submitted, Completed — use a consistent visual treatment across all modules. Whether a student is viewing a fee item or an assignment, the same chip colour and label convention applies. This reduces the learning curve when switching between sections and prevents misinterpretation of state.

Mobile-First Responsive Layouts

Every screen was designed for a 390px viewport first, then adapted upward. This ensured that the core interactions — tap targets, scroll behaviour, and content priority — were optimised for the context where most students would actually use the system, rather than retrofitting a desktop design to smaller screens.

Screens

01 — Login

01 — Login

Clean student login with institutional branding, password visibility toggle, and app store links. Removes unnecessary fields from the legacy web form.

02 — Home

02 — Home

Module launcher with user identity card at the top. Four primary modules (Academics, Accounts, Feedback, Examination) reachable in a single tap.

03 — Dashboard

03 — Dashboard

Unified overview: live GPA, today's class schedule with room numbers, and a notice board. Replaces the legacy multi-page information scatter.

04 — Dashboard (cont.)

04 — Dashboard (cont.)

Scrolled state reveals upcoming assignments with due dates and submission status chips — Pending, Submitted — so students never miss a deadline.

05 — Results

05 — Results

Test results view with score summary, time spent, and per-subject breakdown bars. Tab row (Overview / Questions / Analytics) lets students drill deeper.

06 — Account Summary

06 — Account Summary

Fee dashboard shows total dues vs paid at a glance. Pending/Paid toggle filters itemised rows (Tuition Fee, Lab Fee) with due dates and amounts highlighted in red.

Solution & Outcome

The redesigned ERP consolidates six fragmented modules into one consistent mobile experience. A shared design token set — a single blue primary, neutral grays, and one type scale — ensures every screen feels like part of the same product. Navigation cost dropped from 4–6 taps to a maximum of 2.

Navigation depth was reduced by restructuring the information architecture around student tasks rather than administrative modules. The most-accessed information — timetable, attendance, fees, and results — is now surfaced at the dashboard level, eliminating the intermediate module selection step that previously added friction to every session.

Discoverability improved significantly by replacing module-level menus with a dashboard that proactively surfaces relevant content. Students no longer need to know where a piece of information lives in the system — the interface presents it in context, reducing the time spent searching and the number of navigations required per session.

The unified visual language means students encounter the same card structure, status chips, and spacing conventions across every module. This consistency reduces the learning curve when moving between sections and creates a coherent experience that feels like a single, considered product rather than a collection of disconnected tools.

≤ 2 taps

to any information from home

1 design system

shared across all modules

Mobile-first

100% of screens designed for phones

Validation

The redesigned flows were evaluated through walkthrough-based sessions focused on the five most common student tasks. Participants were asked to complete each task on the prototype without guidance, which surfaced navigation ambiguities and layout issues that weren't visible during design review.

Task-oriented reviews confirmed that the bottom navigation and dashboard structure met the target of reaching any primary information within two interactions. Scenario testing with different screen sizes validated that the mobile-first layouts held up across a range of devices without content overflow or tap target issues.

Walkthrough-based evaluations

Unguided task completion on a click-through prototype to identify navigation friction.

Task-oriented reviews

Five core tasks tested: timetable, attendance, fees, results, and notices.

Scenario testing

Real student contexts used to verify the dashboard prioritisation model.

Feedback sessions with students

Open-ended discussion after task completion to capture qualitative impressions and missing context.

Projects

UX CASE STUDY — AIRAVAT

AIRAVAT

A UX Case Study
Hackathon Platform
Student-led Initiative · 2026

A deep-dive into designing AIRAVAT 3.0 — a national-level 24-hour AI hackathon platform hosted as a student-led initiative. This case study dissects every design decision: from information architecture to the interface that mobilised over 500+ participants.

Begin Reading

₹1,00,000

Prize Pool

24 HRS

Hackathon Duration

4 DOMAINS

AI Tracks

01 — The Problem

Student hackathons
die in the inbox.

Before AIRAVAT 3.0, event discovery for college-level AI hackathons was fragmented. Teams relied on WhatsApp forwards, Instagram stories from society accounts, and last-minute word-of-mouth. Critical information — domains, problem scopes, prize structure, eligibility — lived across multiple posts, none authoritative.

The organising committee needed a single, canonical source of truth: a purpose-built website that could answer every participant question before it was asked, while projecting the credibility and scale of a national-level event.

Core Problems Identified

01

No central information hub

02

Zero social proof or scale signal

03

Registration friction via third-party only

04

Domain scope unclear to applicants

05

No team-formation pathway shown

06

Event credibility hard to communicate

“The interface had to do the job that a hundred Instagram stories couldn't — convert interest into registrations at scale.”

02 — Context & Users

Who Lands Here
& Why It Matters

Primary User

The Builder

Engineering/CS student, 18–22, looking for hackathon credibility signals before investing time registering. Scans fast, decides in seconds.

Clear prize & timeline
Domain relevance
Credibility markers

Secondary User

The Team Lead

Already registered on Unstop, uses site as reference to brief teammates. Needs domain scope depth and organiser contacts.

Domain detail
Contact access
FAQ-style clarity

Tertiary User

The Evaluator

Faculty advisor or corporate mentor evaluating whether to sponsor or mentor. Looks for organisational legitimacy and past credibility.

Organiser credentials
Event branding
Professional presentation

Design Assumptions

Research constraints meant assumptions had to be made. These shaped every layout and copy decision.

01

Most traffic arrives via mobile — Instagram bio links, WhatsApp

02

First-visit bounce rate would be high without strong above-the-fold signal

03

Unstop handles full registration; site's job is to qualify and convert intent

04

Users spend < 15 seconds deciding whether to read further

05

Domain names alone aren't self-explanatory — context copy is critical

03 — Approach

Why It Was Built
This Way

Every design decision on AIRAVAT 3.0 was a deliberate trade-off between speed-to-ship, participant conversion, and communicating organisational credibility — with a zero budget and a two-week deadline.

#
Decision
Rationale
Trade-off
01

Single-Page Architecture

Multi-page navigation would fracture attention on a site where users had a single goal: register or leave. A vertical, scroll-driven SPA let information unfold with momentum.

SEO depth vs. conversion focus — chose conversion.

02

Anchor-Based Navigation

Four nav links (Domains, About, Team, Contact) map to the exact four questions every potential participant has. No friction, no dead ends.

Simple but brittle at scale — acceptable for an event site.

03

Domain-First Content Hierarchy

Domains are the primary decision filter. Healthcare, FinTech, Social, Sustainability — participants self-select here. Showing domains before the About section mirrors the user's mental model.

Assumes users understand AI domain scope — copy carries the weight.

04

External Registration Delegate

Unstop handles identity, team formation, and payment. The site's CTA links directly to the Unstop listing, removing the need to build auth, forms, or a backend.

Loss of first-party registration data — worth the speed of build.

05

Brutalist / Block Visual Theme

The pixel-and-block metaphor aligned with the hackathon's stated theme of assembling ideas. Visual language reinforces conceptual framing.

Novelty has a short half-life — needed to be executed well or not at all.

04 — Structure

Layout Logic &
Information Architecture

Page wireframe — scroll flow

NAV
HERO — Title + CTA + Prize
DOMAIN 01 — Healthcare
DOMAIN 02 — FinTech
DOMAIN 03 — Social Cause
DOMAIN 04 — Sustainability
ABOUT — Event Description
REGISTER CTA
ORGANISING TEAM — Student Committee
CONTACT DETAILS

↳ Each row represents a distinct scroll section. Red = primary conversion point.

Layout principles applied

F-Pattern Reading

Hero content spans full width to capture horizontal scan. Domain cards split into 2-column grid to support the natural drop in reading attention.

Progressive Disclosure

Prize and CTA appear immediately in the hero. Domain detail only reveals on scroll. Team and contact are last — for already-committed visitors.

Visual Weight Hierarchy

Title size is maximal. Section headings use consistent scale reduction. Body copy sits at exactly the right opacity to feel informative, not overwhelming.

Anchor Grid

Nav links are pure scroll anchors. The information architecture mirrors the navigation — what you click is literally what you see next.

05 — Interface

The Interface

Rendered at airavat-3.vercel.app. Deployed on Vercel. Built with Next.js and Tailwind CSS.

Hero ScreenDomains ScreenAbout ScreenOrganising Team Screen

Design tokens observed

Typeface

System-ui / Brutalist heading stack

H1 size

Responsive clamp — ~64–160px

Background

#0A0A0A (near-black)

Primary text

#FFFFFF

Accent

#FF2D20 — retro-red interactive highlights

Border radius

0px — sharp, blocky everywhere

Grid

Full-width sections, 12-col internal layout

Nav position

Fixed top, transparent blur fallback

07 — Output & Delivered Features

What Was
Delivered

View Live Site

The production site at airavat-3.vercel.app was shipped within two weeks of brief. It served as the official event portal for AIRAVAT 3.0 — driving registrations from across India.

F01Core

Responsive Single-Page Layout

Fully fluid from 320px to 4K. Navigation collapses gracefully on mobile. Domain cards reflow to single-column without layout breaks.

F02Content

Four AI Domain Tracks

Healthcare, FinTech, Social Cause, Sustainability. Each with standalone scope descriptions that answer the participant question: can I build something relevant here?

F03Conversion

Dual-CTA Architecture

Register Now appears in the hero and in the about section, ensuring every scroll depth has a conversion point. Explore anchor reduces bounce on undecided visitors.

F04Trust

Organiser Credibility Section

National-level hackathon and student-led co-branding. Named team members with direct phone contacts. Eliminates the 'who is behind this?' objection.

F05Architecture

Zero-Backend Registration

All registration logic delegated to Unstop. The site serves as a qualification and intent layer — zero auth, zero forms, zero backend maintenance.

F06Performance

Vercel Edge Deployment

Static-first rendering via Next.js. Global CDN via Vercel Edge Network. Sub-second load times globally — critical for a campaign where first impressions are make-or-break.

2 weeks

Design to deploy

500+

Targeted participants

4 domains

Covered tracks

08 — Impact & Reach

Impact & Reach

The design and accessibility of the platform successfully converted interest into concrete participation, demonstrating measurable engagement metrics over its active lifecycle.

Platform Analytics — OverviewPlatform Analytics — Breakdown

500+

Total Users Reached

The platform served as the central hub, reliably handling traffic spikes during the registration phase and actively engaging over 500 unique builders.

Multiple

Countries Engaged

Vercel Edge network ensured fast load times, allowing the platform to reach and register participants beyond immediate geographic constraints.

Sustained

Post-event Traffic

The platform continued to receive steady organic traffic post-completion, establishing a strong digital footprint for future editions.

09 — Learnings

Reflections

Honest evaluation of what shipped, what misfired, and what would be built differently with more time and data.

What Worked

Single-page scroll flow

The decision to keep everything on one page was correct. It eliminated navigation dead-ends and let the content build momentum naturally. Bounce metrics were low among users who landed via direct link.

Anchor-based navigation

Four nav links mapped directly to the four user questions. This clarity reduced confusion — every user knew exactly where they were and what came next.

Above-the-fold prize visibility

Showing ₹1,00,000 immediately in the hero was the single most effective conversion signal. It answered the first and most important question before any interaction.

Named contacts instead of forms

Displaying real names and phone numbers (not a contact form) created a sense of human accountability. Users reported feeling more comfortable asking questions.

Domain-first content ordering

Placing domains before the About section aligned with participant mental models. The first question is always domain relevance, not organisational backstory.

What Fell Short

No search or filtering on domains

With only 4 domains, this wasn't critical. But as the event scales, participants with niche interests would benefit from domain comparison or filtering tools.

No team-formation support

Many solo participants wanted a way to find teammates. The site had no mechanism for this — fully delegated to Unstop, which added friction for solo builders.

Static prize structure with no FAQ

Prize breakdown, team size limits, and judging criteria generated repeated contact queries. A structured FAQ would have deflected this volume.

No countdown timer

A live countdown to registration close or the event start would have created urgency without requiring any copy changes. Missed conversion opportunity.

If built again — v2 improvements

01

Add a live countdown timer to the hero section

02

Build a team formation board or connect with Discord server

03

Add an FAQ accordion section to pre-answer common queries

04

Implement OG image generation for social sharing previews

05

Add domain problem statement PDFs for download

06

Create a past edition section to build multi-year credibility

07

Consider a dark/light mode toggle for accessibility

Projects

HEALTHCARE AI PLATFORM — PROSCRIPT

Healthcare AI Platform · 2025

PROSCRIPT

Full-Stack + Machine Learning · AI-Driven Prescription Assistant

01 — The Problem

Medical information shouldn't be lost in handwriting.

Traditional prescriptions often contain handwritten notes, abbreviated drug names, and fragmented medical information that can be difficult for patients to understand. Important medication instructions, dosage details, and potential risks are frequently buried within unstructured documents.

Patients may also struggle to identify whether prescribed medicines conflict with existing treatments or whether recommendations are relevant to their demographic profile. Without a structured interpretation layer, prescription data remains inaccessible to the people who need it most.

The challenge was to create a system capable of converting raw prescription data into structured, understandable, and actionable medical insights — while maintaining safety by flagging potential risks before they become problems.

01

Handwritten prescriptions difficult to interpret without clinical training

02

Medical information stored in unstructured formats with no machine-readable layer

03

Potential drug interaction risks often overlooked during manual review

04

Limited contextual guidance available for patients post-consultation

05

Prescription review processes remain time-consuming for both patients and staff

06

Lack of personalised recommendation support based on patient demographics

02 — Objectives

01

Extract text from prescription images using OCR

02

Structure medical information automatically from raw input

03

Detect dosage inconsistencies and potential drug conflicts

04

Generate contextual medical assistance via LLM integration

05

Improve accessibility of prescription information for patients

06

Support patient-specific recommendations using similarity matching

03 — Approach

Six phases. One unified prescription pipeline.

PROSCRIPT was built in structured phases, each layer adding intelligence on top of the last. OCR converts raw images into text; NLP normalises that text into medical entities; retrieval and rule engines validate safety; and a large language model provides contextual assistance — all within a single API-backed workflow.

The decision to separate each processing stage into an independent service made the system easier to test and iterate. Each phase could be validated in isolation before integrating into the full pipeline, reducing the surface area for bugs in a domain where accuracy is critical.

01

Phase 01 — OCR pipeline using EasyOCR for prescription image digitization

02

Phase 02 — Medical text processing and normalisation of extracted content

03

Phase 03 — TF-IDF vectorization and demographic-aware patient similarity matching

04

Phase 04 — Rule-based validation engine for dosage and medication conflict detection

05

Phase 05 — Llama 3 integration for contextual medical query understanding

06

Phase 06 — Full-stack deployment with secure API communication and database integration

04 — System Architecture

Frontend

React

Backend

Node.js · Express.js

AI Services

FastAPI · Llama 3 · TensorFlow

Data Layer

MongoDB

Document Processing

EasyOCR

Recommendation Engine

TF-IDF Vectorization · Similarity Matching

05 — Key Features

Intelligent Prescription Parsing

EasyOCR extracts raw text from uploaded prescription images. A normalisation layer then maps abbreviated drug names, dosage notations, and clinical shorthand to structured medical entities that downstream services can process reliably.

Drug Interaction Detection

A rule-based validation engine cross-references extracted medications against known interaction patterns. Conflicting drug combinations are flagged with contextual explanations, giving users actionable information rather than a raw warning.

Dosage Conflict Analysis

Extracted dosage values are validated against standard reference ranges for each identified medication. Anomalies — whether unusually high doses or incompatible combinations — are surfaced before the prescription is processed further.

Contextual Medical Assistance

Llama 3 is integrated as a conversational layer over the structured prescription data. Patients can ask natural language questions about their prescriptions — dosage timing, side effect profiles, dietary restrictions — and receive grounded, context-aware responses.

Patient Similarity Matching

TF-IDF vectorization of symptom and demographic data enables retrieval of comparable patient profiles from the database. This supports personalised recommendation generation without requiring large-scale clinical data, using structural similarity as a proxy for relevance.

Structured Medical Records

All parsed prescription data is stored in MongoDB as structured documents — medications, dosages, instructions, flagged interactions — making records searchable, auditable, and ready for downstream processing or export.

06 — Challenges

OCR Variability

Prescription images varied significantly in quality, handwriting style, and formatting. Pre-processing steps — contrast normalisation, skew correction, and noise reduction — were added to improve EasyOCR accuracy across diverse input conditions.

Medical Text Normalisation

Clinical abbreviations, brand name vs. generic name mismatches, and non-standard dosage notation required a dedicated normalisation layer before any downstream analysis could be performed reliably.

Retrieval vs. Rule-Based Balance

Balancing retrieval-based patient similarity recommendations with deterministic rule-based medical validation required iterative refinement. The two systems operate on different data representations and needed careful interface design to avoid conflicting outputs.

System Integration Complexity

Integrating OCR, machine learning pipelines, and LLM-based assistance into a unified workflow across React, Node.js, FastAPI, and MongoDB demanded careful API contract design and extensive end-to-end testing to ensure consistent data flow.

07 — Outcome

PROSCRIPT demonstrates how OCR, machine learning, retrieval systems, and large language models can work together to improve prescription understanding and medication safety.

The platform successfully transforms fragmented prescription information into a structured workflow that supports interpretation, validation, and contextual assistance — replacing a manual, error-prone process with an automated pipeline that surfaces the right information at each step.

By separating concerns across six discrete processing phases, the system remains extensible. Each layer can be improved or swapped independently as better models or data sources become available, without requiring changes to the full stack.

OCR-Powered Prescription Analysis

TF-IDF Recommendation Engine

Drug Interaction Detection

Llama 3 Medical Assistant

Full-Stack Architecture

Healthcare-Focused AI Solution

Project Demo

Experience

WORK & LEADERSHIP

SPTBI (Transpure) — Software Testing & Development Intern

Spring Boot · Postman · API Testing

Sept 2025

Automated API testing workflows using Postman, reducing manual testing time for backend feature integrations.

Engineered Spring Boot modules including a dynamic online form generator that streamlined remittance workflows.

IEEE Computer Society, SPIT — Vice Chairperson

Leadership · Events · Sponsorship

Sept 2025 – Present

Spearheading marketing and sponsorship strategies for Airavat 3.0, a national-level AI hackathon.

Organised the International Quantum Computing Conclave, coordinating logistics for leading researchers from IIT Madras and C-DAC to strengthen campus research culture.

Engineering

PROJECTS

ZeroVault

ZKP-Based Password Manager · Flask, MERN, AES, Schnorr ZKP · Oct 2025

Zero-Knowledge Proof based password manager enabling secure, passwordless authentication.

Schnorr protocol for ZK authentication without revealing secrets; AES-256 client-side encryption so no plaintext password ever leaves the device.

Modular Flask backend for ZKP verification and encrypted vault handling, integrated with MongoDB.

File Vault

Secure File Storage & Management · Go, React (Vite), PostgreSQL, Nginx · Dec 2025

Dockerized full-stack file vault using Go, React, PostgreSQL, and Nginx for secure auth, upload, sharing, and storage.

SHA-256 deduplication with a trie-based directory structure for O(log n) lookups at scale.

System security via JWT, bcrypt, rate limiting, audit logs, protected links, and CORS policies.

InsureIllm

Knowledge Assistant · RAG, GPT-4o-mini, Chroma · Sept 2025

Internal Q&A assistant using a RAG pipeline with semantic chunking and Chroma embeddings.

Gradio chat UI with GPT-4o-mini for low-cost, high-accuracy contextual responses.

Improved retrieval quality using reranking, query rewriting, and MRR/nDCG evaluation.

Proscript

AI-Driven Prescription Assistant · React, FastAPI, TensorFlow, OpenAI · Apr 2025

Processed unstructured symptom data using TF-IDF vectorisation and standardised patient demographics for similarity matching.

Flagged risky drug interactions using rule-based analysis and OCR-based prescription parsing.