// Project 01 · Now
Student Platform · AI
PAC University
- Problem
- Students needed one place for courses, schedules, files and help, and every question waited for staff.
- Solution
- One student app on web, Android and iOS with LMS, Calendar and Drive built in, and PAC Agent, a Personal Academic Copilot for study help, deadlines and support tickets, also inside ChatGPT.
- Delivered in 20 days by a team of 4 I lead
- PAC Agent helps with study and assignments, shares deadlines, raises support tickets
- Also inside ChatGPT as a ChatGPT plugin, connected through MCP
- Web, Android and iOS, with real-time chat
Problem - students needed one place for courses, schedules, files and help, and every question waited for staff.
Built - a web, Android and iOS student app with LMS, Calendar and Drive integrations, an AI agent (PAC Agent, the Personal Academic Copilot) that helps with assignments and study, tells students their deadlines, and raises support tickets for technical issues and reports their status, also available as a ChatGPT plugin connected through MCP, and real-time chat; as team lead of 4 engineers.
Outcome - the platform was delivered in 20 days on web, Android and iOS, with AI-assisted coding across the stack.
Trade-off: AI-assisted coding bought the 20-day timeline; every change still went through review and tests, because speed without them is just faster bugs.
DjangoReactFlutterLangGraphVertex AIMCPKafka
READ CASE STUDY →
// Project 02
GenAI Platform
CygnusAlpha
- Problem
- Enterprise support teams answered the same questions all day, and a demo chatbot couldn't survive real load.
- Solution
- A GenAI platform where AI agents, on chat and voice, answer from live company data and hand the hard cases to people.
- 5+ enterprise clients, incl. Badho.in and Ferns N Petals
- Chat, email, social, voice bots and automated follow-up calls
- 10,000+ concurrent requests, <200ms p95, 99.9% uptime
- Support response 60% faster, ~$200K/yr saved
Problem - enterprise customer operations that needed AI automation able to hold up under real load, not a demo.
Built - event-driven microservices on Django, FastAPI, Kafka, PostgreSQL, Redis, Elasticsearch, and Neo4j, with LangChain/LangGraph RAG pipelines and multi-agent systems over Pinecone and ChromaDB.
Outcome - 5+ enterprise clients at 10,000+ concurrent requests under 200ms p95 on a 99.9% uptime SLA; support response time down 60%, ~$200K/year in operating cost removed.
Trade-off: two vector stores - Pinecone for the managed production path, ChromaDB for local iteration and evals - some duplication in exchange for not running vector infrastructure ourselves.
DjangoFastAPILangGraphKafkaPineconeRedis
READ CASE STUDY →
// Project 03
Traffic Infrastructure
NHAI ATMS
- Problem
- Operators couldn't watch hundreds of cameras, and each vendor's system worked on its own.
- Solution
- One AI control room that spots incidents and alerts response teams in seconds, with automatic speed detection and ANPR, and 24x7 surveillance.
- Live across 580+ km on three corridors
- Incident response 40% faster
- Many vendors' cameras, sensors and signboards in one system
Problem - monitor and manage traffic across the Delhi–Mumbai Expressway in real time, with four-plus vendors' systems that didn't talk to each other.
Built - as Master System Integrator: a centralised event-driven pipeline on Django, React, Kafka, RabbitMQ, MySQL, and Airflow, integrating six AI/CV modules - VIDS, VSDS, VMS, ANPR, ADAS, and pothole detection.
Outcome - live across 580+ km on three corridors - Sohna–Dausa, Delhi–Vadodara, Vadodara–Mumbai; incident response time down 40%. Demonstrated to Union Ministers and the Haryana CM in Feb 2024, unlocking $2M+ in expansion.
Trade-off: prioritised operator-verified alerts over full automation - fewer false dispatches at the cost of some latency on edge cases.
DjangoKafkaRabbitMQComputer VisionReact
READ CASE STUDY →
// Project 04
IoT Platform
TMCC
- Problem
- Toll plazas went down with no central view, and drivers reported failures before any alert did.
- Solution
- Live equipment monitoring and one data lake across every vendor's plazas.
- 1,500+ toll plazas monitored live
- Downtime down 30%, ~$500K/yr recovered
- Issue resolution 50% faster
Problem - toll plazas across India going down with no central view of their health - every outage was lost revenue.
Built - a pan-India IoT platform aggregating real-time health data from 1,500+ plazas into a toll data lake on AWS (RDS, S3) with Apache Druid, Airflow, Superset, and custom ETL, feeding integrated analytics and automated ticketing.
Outcome - 1,500+ toll plazas monitored; toll downtime down 30% (~$500K/year in recovered revenue), issue resolution 50% faster.
Trade-off: ran Druid and custom ETL on AWS instead of a managed warehouse - more to operate, but full control over ingestion from 1,500+ heterogeneous plaza feeds.
AWSDruidAirflowDjangoIoT
READ CASE STUDY →
// Project 05
Alexa Skill
9XM Bade Chote
- Problem
- 9XM wanted its Bade Chote jokes on Amazon Alexa, so listeners could ask for a joke by voice.
- Solution
- An Alexa skill that hears “open Bade Chote Jokes” and answers with a joke.
- Live on Amazon.in, published under 9XM
- Built, deployed and maintained end to end
- Voice only: no screen needed
Problem - 9XM wanted its Bade Chote jokes on Amazon Alexa, so listeners could ask a smart speaker for a joke by voice.
Built - an Alexa skill that hears the request and answers with a Bade Chote joke, with the server set up and the skill deployed and maintained end to end.
Outcome - the skill went live on Amazon.in, published under 9XM.
PythonJavaScriptAlexa Skills Kit
// Project 06
AI Agent · HR
AgenticX
- Problem
- Employees hunted for HR policies, and every leave or timesheet change went through HR.
- Solution
- One AI assistant that answers policy questions and does routine HR work itself.
- Policies, leave, timesheets and HR requests in one chat
- Requests resume after failures (durable workflows)
- Specialised agents that work together
Problem - employees hunted through documents and emails for company policies, and every leave request, timesheet change or HR question became a ticket or a message to HR.
Built - a company-wide AI agent that answers from company policies, applies for leave, updates timesheets and handles other HR requests, on durable workflows (Temporal, LangGraph) that connect to company systems through MCP and A2A.
Outcome - one assistant for policies, leave, timesheets and HR requests, with multi-step requests that resume exactly where they stopped through deploys and failures.
Trade-off: Temporal's determinism constraints shape how agent code is written - a learning curve traded for replayable, auditable runs of every request.
TemporalMCPA2ALangGraph
READ CASE STUDY →
// Project 07
GovTech
Samriddhi
- Problem
- Field workers had to collect welfare data in villages with no internet.
- Solution
- An offline-first app with supervisor checks and district-level dashboards.
- 1,000+ Self-Help Groups in rural Chhattisgarh
- Benefits guided to 50,000+ people
- Processing time down 40%
Problem - 1,000+ Self-Help Groups across rural Chhattisgarh (CGSRLM, with Pradan) collecting financial data where connectivity can't be assumed.
Built - an offline-first Android app with sync and conflict resolution, plus a centralised analytics layer on Django, PostgreSQL, Druid, Airflow, and Superset.
Outcome - data-driven benefit distribution to 50,000+ beneficiaries; processing time down 40%.
Trade-off: offline-first means every record can be edited in two places - sync with explicit conflict resolution costs UX complexity, but never silently loses a field worker's data.
AndroidDjangoDruidSuperset
READ CASE STUDY →
// Project 08
EdTech Marketplace
Otootuitions
- Problem
- Thousands of teachers to screen and match to the right student.
- Solution
- Screening tools, verified onboarding, and apps for teachers, parents and students.
- 40,000 teachers and 25,000 students
- 200 partner institutions
- 98% student success rate
Problem - a one-to-one tuition marketplace that had to screen thousands of teachers and match each student to the right one, across teachers, parents and students.
Built - web and mobile apps for all three groups, an admin panel for teacher screening, and a verified pre-onboarding checklist; I owned code review, deployment and architecture.
Outcome - a network of 40,000 teachers and 25,000 students across 200 institutions, with a 98% student success rate.
Trade-off: a strict onboarding checklist slows teacher sign-up - accepted, because the platform's reputation is the quality of its teachers.
DjangoMySQLSuperset
READ CASE STUDY →
// Project 09
Video Security SDK
56 Secure NVR
- Problem
- Three apps needed to talk to network video recorders through another company’s APIs.
- Solution
- One NVR SDK, a single integration layer built into the Android, iOS and web apps.
- One SDK for Android, iOS and web
- Solution architecture and AWS production servers
- Worked with Uniview’s team in China
Problem - 56 Secure’s apps on Android, iOS and the web each needed to work with network video recorders, through APIs owned by the recorder maker’s team in China.
Built - an NVR SDK: one integration layer over the recorder APIs, built into all three apps, with the solution architecture and the production servers on AWS; as lead engineer and solution architect.
Outcome - the SDK shipped inside 56 Secure’s base app on Android, iOS and web.
DjangoMySQLNVR APIs
READ CASE STUDY →
// Project 10
Accident Reporting App
Anonymous Citizen Ping
- Problem
- People who see an accident needed a way to report it anonymously, with live video.
- Solution
- An app with live video streaming and a backend built from scratch.
- Anonymous accident reports
- Live video from the scene through AWS Kinesis
- Built from scratch for Inkers Technology
Problem - people who see an accident needed a way to report it anonymously, with live video from the scene.
Built - the app’s backend from scratch, its APIs, dynamic pages, and live video streaming through AWS Kinesis, for Inkers Technology.
Outcome - accidents reported anonymously with live video, in an app built from scratch.
DjangoDRFAWS Kinesis
READ CASE STUDY →
// Project 11
AgriTech Platform
Adapt Odisha
- Problem
- Farmers’ data had to be collected in one place and turned into analytics.
- Solution
- A platform that collects the data and shows analytics on it.
- Farmer data collected in one system
- Analytics built on that data
- Backend and APIs built from scratch
Problem - farmers’ data in Odisha had to be collected in one place and turned into analytics.
Built - the backend from scratch, the APIs for data collection and analytics, and deployments to staging and live.
Outcome - farmer data collected and shown as analytics on one platform.
DjangoDRF
READ CASE STUDY →
// Project 12
Plant Adoption Platform
ChallengeForGreen
- Problem
- An in-house idea needed a working product for adopting plants online.
- Solution
- A website with a backend and APIs built from scratch and a React front end.
- Adopt a plant online
- Backend and APIs built from scratch
- React front-end fixes, staging and live deploys
Problem - an in-house idea needed a working product: a website where people could adopt plants online.
Built - the backend from scratch, its APIs, fixes on the React front end, and deployments to staging and live.
Outcome - the platform went live with its backend, APIs and front end in place.
DjangoDRFReact
READ CASE STUDY →
// Project 13
HealthTech Platform
Hospital Management System
- Problem
- Several hospital vendors needed one system, with different access for patients, doctors and staff.
- Solution
- A multi-vendor hospital platform with role-based logins and live video, built from scratch.
- Separate logins for patients, doctors and staff
- Live video streaming built in
- Backend and APIs built from scratch for Inkers Technology
Problem - several hospital vendors needed one system, with different access for patients, doctors and staff.
Built - a multi-vendor hospital platform on Django with DRF APIs, role-based logins, live video streaming and dynamic pages, for Inkers Technology.
Outcome - one platform with separate logins for patients, doctors and staff, built from scratch.
DjangoDRFLodash
READ CASE STUDY →
// Project 14
Payments SDK
Amazon Pay SDK
- Problem
- A client needed to take Amazon Pay payments from a Python backend.
- Solution
- A Python payment SDK for Amazon Pay, built in Flask to the client’s requirements.
- Python SDK for Amazon Pay
- Requirements gathered directly with the client
- Built from scratch in Flask
Problem - a client needed to take Amazon Pay payments from a Python backend.
Built - a Python payment SDK for Amazon Pay, built from scratch in Flask after gathering the requirements with the client.
Outcome - a Python SDK for Amazon Pay, delivered to the client’s spec.
PythonFlask
READ CASE STUDY →
