Full-stack engineer in Delhi. At UnQue I shipped booking, payroll, attendance and access control for a salon SaaS of 40 businesses, where the booking bot I built grew bookings 3× to 10,000 a month. At Rocket Health I prototyped the in-house scheduler to replace Calendly. Now building LLM agents with tool-calling and RAG — and I like the boring parts of the stack: the constraint that stops the double-booking, the queue that keeps the hot path off the database.
Each one is a full case study: the problem, what I built, the architecture, the hard parts, and the proof. The exchange's matching engine runs right here, on your CPU.
A Telegram concierge that books salon appointments, safely.
An agent on Telegram that books, reschedules and cancels salon appointments through plain chat, taking real actions on a SQLite database via Gemini tool-calling. Guardrailed so it never invents a price or a slot, with per-user state for multi-step flows — verified by an automated eval passing 10/10 scenarios.
A Binance-style exchange, with the matching engine running in this page.
A trading exchange modelled on the Binance API, serving mock local pairs alongside live pairs proxied from Backpack. Orders match in a single-node in-memory engine — 5,000 a second at sub-5ms — while durability stays off the hot path through 3-second snapshots and a Redis replay queue.
Ask questions of your own documents, and get an answer that cites them.
Upload PDFs or text and a FastAPI service chunks and embeds them into ChromaDB. A Gemini agent decides when to search, answers from the retrieved passages, and says “I don't know” when they don't cover the question. Dockerised and deployed on Render.
Messaging that re-renders one conversation, not the whole list.
Real-time messaging with instant delivery, typing indicators, presence and persistent history. The interesting work was the state layer — restructured so an incoming message re-renders the conversation you are reading, not the entire list behind it.
A constraint, not a code review, stops the double-booking.
Two customers hit the same slot in the same second. The fix that held in production was a unique index on the slot, not a check in the handler.
Every number on this page came out of a system that ran.
5,000 orders a second is a local load test, and it says so. The 10/10 on the salon agent is an eval script in the repo you can run yourself.
Build, containerise, deploy, hand off.
Releases went from 40 minutes to 5 because I owned the pipeline too — Docker, automated AWS deploys, and a runbook someone else could follow.
An agent that cannot invent a price is worth more than one that sounds clever.
System prompts, tool-calling and retrieval keep the LLM inside what is true: it books real slots, quotes real prices, and says “I don't know” when the documents don't cover it.
Grouped by the job they do. Nothing here is on the list because it was fashionable; each one has shipped something that people use.
Interfaces that stay correct while the data underneath them changes.
Boring, observable services with explicit contracts.
The invariant lives in the database, not in the handler.
Agents that take real actions and stay inside what is true.
If it is not in a pipeline, it has not shipped.
I started with a BCA at GGSIPU in Delhi and a question that never went away: what happens when a hundred people press the same button at the same moment. Most of what I have built since is an answer to that — booking, payments, access control — the parts people only notice when they break.
At UnQue I went from intern to leading a team of four, shipping booking, payroll, attendance and role-based access for a salon SaaS across 40 businesses. At Rocket Health I prototyped the scheduler to replace Calendly, with double-booking prevented by a database invariant. Along the way I rebuilt a release pipeline so a deploy took five minutes instead of forty.
Lately the interesting problems sit where LLMs meet real systems: agents that take actions, retrieval that cites its sources, evals that catch regressions. I like the boring parts of the stack, so the product can be the exciting part.
From a first commit in a BCA lab to leading a team of four. The thread is the same every time: make it stay correct when real traffic shows up.
Prototyped the in-house scheduler to replace Calendly — availability engine, round-robin assignment and Google Calendar integration, with double-booking prevented by a database invariant. Closed two revenue leaks in the React Native checkout (a coupon redeemable more than once, payments against lapsed reservations) with redemption validation and a slot-expiry countdown, covered by Jest. Cut product-bundle loading from 6 API calls to 1 with a single NestJS and Prisma endpoint.
Grew from intern to leading a team of four. Shipped booking, payroll, attendance and role-based access for a salon SaaS of 40 businesses, where the booking bot I shipped grew bookings 3× to 10,000 a month over five months. Eliminated a production double-booking race with a unique database constraint, and cut releases from 40 minutes to 5 by containerising with Docker and automating AWS deploys.
Delivered three flows end to end from Figma designs — authentication, profile management and reporting — as responsive React interfaces, and extracted shared UI into reusable components adopted across later features.
JIMS Vasant Kunj. Where the question about a hundred people pressing the same button started.
Both written on LinkedIn by people who saw the work up close: the co-founder who managed me at UnQue, and a client I built for.
I had the opportunity to manage Chirag during his time at UnQue, where he worked as part of our engineering team and contributed to several areas of our product and backend systems. During his time with us, he worked with technologies including Node.js, TypeScript, MongoDB, and APIs, and was involved in production workflows across bookings, payments, memberships, referrals, and other business-critical features. As his manager, I found Chirag to be a curious and dedicated developer who was willing to take ownership of tasks, investigate issues deeply, and work through complex problems in an evolving product environment. He consistently showed a strong willingness to learn, improve his technical understanding, and take on new challenges. I appreciate his contributions to the team and wish him the very best in his future career.
Chirag interned and worked with my small business on a project focused on building, integrating, and testing website during August and September 2025. Throughout this time, he demonstrated curiosity and a strong desire to contribute, offering various solutions. He possesses a good understanding of backend technologies, custom software and relevant industry knowledge. I endorse him for his practical skills and knowledge. Best of luck with all your future pursuits.
Open to full-stack and applied-AI roles — immediate joiner, open to relocate. Email is the fastest way to reach me, and I reply within a day.