Kumar Prateek

Keeping fulfillment up when its dependencies aren't

An order at Zepto lives in several systems: the ordering system, the warehouse, and last mile. Each holds its own view of where the order is. Keeping fulfillment up at millions of orders a day came down to a few things I designed for. Fallbacks for every downstream, so a dependency being down degrades something instead of stopping picking. A minimal set of services that genuinely have to be up for an order to move, with everything else allowed to lag. Eventual consistency of status across systems, rather than trying to keep them in lock-step. And auto-healing: idempotent writes, automatic retries for transient failures, and reconciliation loops that find and repair disagreements without anyone on call. The same principle runs through how inventory stays consistent across services: nothing in the path needs to be right the first time, it only needs to be safe to run again.

An AI development flow that knows the company

Everyone was already using coding agents. The problem was that the quality of what came out depended almost entirely on who was prompting, and none of the agents knew anything about the company. Not the specs, not the schemas, not why a service looks the way it does.

So I built one that does, on the Claude Agent SDK. I designed the flow and wrote the core of it: the agent, the context it's grounded in, the tools it's allowed to reach, and the accounting that tells us what each kind of use costs. The interesting part wasn't putting an agent in front of an engineer. It was giving the agent enough of the company's context that the engineer didn't have to explain the company to it every time. On top of that, one flow everyone goes through: ask, plan, then code and test, with the same skills for everyone, so the result depends on the spec rather than on who typed the prompt. Anyone can ask how something works, propose a design, and carry it to a reviewed PR.

Building it also made a question harder to ignore: how much of building software can we hand to machines before engineers stop understanding the systems they're responsible for? That's where grask came from.

Building the warehouse system, then everything around it

I joined when Zepto was replacing its warehouse software with its own. I built core services of the in-house warehouse management system from scratch, inbound first: purchase orders, receiving, put-away. Then took it into production, onto Kubernetes, with the monitoring and alerting that let a small team run it.

Once it was running, the job became widening it. I led the split of the monolithic warehouse order system into separate B2B and B2C services, and the zero-downtime migration that came with it. Then the business kept opening new ground, and the same platform had to cover it. We built an in-house kitchen management system on top of it. We added vendor returns and customer returns. And we started fulfilling pharmaceutical SKUs, which come with their own rules on storage, batches and expiry that the system had to enforce.

Pricing and promotions

Three years on the services that decide what a room costs, and whether you get a discount on it. I started by carving the coupon service out of the Ruby monolith and rewriting it in Java as a rule-based discounting engine that evaluates a coupon against many parameters at once, on the hottest API in the booking flow. From there I owned the deals platform and grew it from a handful of offer types to the full range the business wanted, and then OYO Money discounting, which I reworked until it stopped being the slow part of checkout.

The bigger piece was architecting the promotions platform that replaced the pile: coupons, offers, merchant discounts, flash sales, new-user and free-night deals under one model, where the business team creates an offer, a hotel owner subscribes to it, and a guest redeems it. OYO Vacation Homes had been running its own pricing and discounting stack; I designed the migration that folded it into the same platform, so there was one system to operate and a new property type could be onboarded in a fraction of the time.

I also led the move of the pricing and promotions stack to a new cloud with no data loss.