Harsh Gaur

Hardware first

B.Tech CSE (IoT) · RKGIT, Ghaziabad

I came into software through hardware. My degree was computer science with an IoT specialisation, and what actually held my attention was devices and the systems around them — sensor networks, how a physical thing talks to a server, what happens when the network is unreliable. The project that made it click was an RFID door-lock access system: a reader, a controller, an access policy, and a server that had to stay correct even when the link dropped.

That's a small system, but it has the shape of every system I've worked on since — something at the edge producing messy input, something in the middle deciding what it means, and a store of record that has to stay consistent regardless.

Learning how production apps actually work

September 2024 · React Native intern → full-time, February 2025

I joined Mulltiply on 23 September 2024 as a React Native intern, and moved to a full-time engineering role in February 2025. The company builds B2B commerce for Indian retail — a buyer app for retailers and a management app for distributors — and I was handed real screens in a real codebase from the start.

What I was really learning was how apps like Blinkit and Zomato hold together at production scale: how state is managed when every screen needs live stock and pricing, how navigation and deep links behave when a notification can drop you anywhere in the app, and why rendering performance stops being a detail once your list has thousands of SKUs in it. I started by building modules and profiling the slow ones, which is a good way to learn a codebase — you have to read everything.

Owning the retailer app

2025 · MulltiplyR

Over 2025 I took on MulltiplyR, the retailer-facing quick-commerce app, and ended up its second-highest contributor of fourteen across the project's whole history. I authored sixteen screens and twelve reusable components — payments, wallet, credit applications, bulk quotes, seller comparison, shop onboarding — plus the app's analytics layer and its lazy-loading architecture.

The piece I'm most pleased with is the home experience. Rather than hardcoding the home screen, we built it so the admin panel controls which modules appear, in what order, and with what content — deals, tickers, recommendations, advertisements, quick-order lists — and the app renders whatever the backend describes. That pattern is called Server-Driven UI, and it's the same approach Blinkit and Swiggy use: merchandising changes ship without an app release, and you can reorder a storefront for a campaign in minutes instead of waiting on review.

Both apps shipped — MulltiplyR is live on the App Store, and the distributor app (shipped as MulltiplyAI on iOS) is live on both Google Play and the App Store.

The switch to backend

December 2025

In December 2025 I moved to the backend, and I can point at the exact commit. My first branch was interaction_preference, and the first thing I built was a user preference and interaction scoring system — capturing what a retailer browses, searches and reorders, turning that into preference scores, and using pgvector semantic similarity to connect those signals to items they had never explicitly looked at.

It was a good first backend project precisely because it wasn't only backend. It needed a schema that could absorb a high write volume of interaction events, embeddings that stayed meaningful as the catalogue changed, and an LLM step to make the output explainable to a human. Within the same fortnight I was also working on search — the beginning of the Hinglish query parser I still maintain.

Backend, with AI in the middle of it

2026 · present

Since then I've worked almost entirely on distributed backend systems, and in practice most of them have an AI component somewhere in the path rather than bolted on at the edge. I built a search layer that compiles natural-language Hindi and Hinglish queries into structured search filters; a recommendation engine that blends vector similarity with behavioural co-occurrence; an OCR pipeline that turns photographed invoices into order lines with an LLM structuring pass; and voice ordering, which is speech to transcript to parsed cart.

The less glamorous half is the part I'd argue matters more: event-driven queues and workers, a configurable notification rules engine that took routine changes off the deploy path, and bidirectional synchronisation with four different ERP systems that were never designed to be integrated with. Across all of it I've authored 2,483 commits and created sixteen backend modules from scratch.

What I'm working on next is the infrastructure layer underneath all this — Kubernetes and ArgoCD, Postgres query planning, and multi-agent orchestration with LangGraph. I like problems where the input is unpredictable and the output still has to be exactly right.