ChefKart · Associate Software Engineer

Building every path into a ChefKart booking and the systems that fulfil it

Customers could arrive in different ways. Some discovered ChefKart through a Google search and a city page. Others opened the mobile app directly, selected their location and checked which services were available nearby.

I helped build these customer paths and the operational systems behind them across ChefKart’s React Native app, Next.js website, payment application and internal operations dashboard.

Gurugram · Onsite · December 2025 – Present

Explore the work Talk to me

React Native · Next.js · TypeScript · Redux · Razorpay · SSR · REST APIs

One service, four products

Website · Next.js
Search and campaign customers arrive
- City pages
- Cooks Near Me
- Campaign pages
Customer app · React Native
Direct and returning customers book
- Book by Dish
- Wallet
- Cashback
- Party booking
Payment application · Payments
Payments are executed and confirmed
- Payment status
- Transaction types
Operations dashboard · React
The team fulfils the visit
- Visit tracking
- SOS alerts
- Cook operations

Recognised in Technology & Engineering, May 2026

#1Of 18 app contributors

#1Of 13 website contributors

461Authored commits

107,794Surviving source lines

#1Of 18 app contributors

#1Of 13 website contributors

461Authored commits

107,794Surviving source lines

35.05% of the app’s and 33.18% of the website’s current source-code ownership. See the full evidence

Who I built for

Three ways people booked a home cook

ChefKart lets people book a professional cook for their own kitchen. Customers got there in three different ways, and I worked on the screens behind all three.

An Indian woman chef in a black chef jacket stirring curry in a kadai on a gas stove in a home kitchen — Where every path ends: a professional cook in your kitchen

Through a Google search
They landed on a city or Cooks Near Me page from search, checked that ChefKart served their area, looked at what was on offer and started booking on the website.
Straight from the app
They heard about ChefKart from a friend, an ad or the app store, signed up, set their location, checked availability and booked without ever leaving the app.
Coming back to book again
They opened the app to book again, manage an upcoming visit, pay what was left, change their cook, share feedback or get help from support.

From booking to visit

After booking, the journey is the same

Website or app, every booking then followed the same steps, with an operations team making each visit happen.

Starting on the website

4 steps

Google search or ad
City or service page
Check your area
Choose a service

Google search or ad
City or service page
Check your area
Choose a service

Starting in the app

4 steps

Open the app
Sign up
Check your area
Choose a service or dish

Open the app
Sign up
Check your area
Choose a service or dish

Then, for everyone

5 steps

Book
Pay
Cook visits
Make changes or get help
Give feedback and book again

Book
Pay
Cook visits
Make changes or get help
Give feedback and book again

Book
Pay
Cook visits
Make changes or get help
Give feedback and book again

Behind the scenesOperations dashboard

5 steps

I worked on both sides: the screens customers used, and the dashboard the operations team ran every visit from.

Booking comes in
Cook and time slot assigned
Visit tracked
Problems handled
Visit completed

Booking comes in
Cook and time slot assigned
Visit tracked
Problems handled
Visit completed

What I worked on

The four products behind every booking

Each one handled a different part of getting a cook into someone’s kitchen.

React Native app
The customer app. It took people from signing up and setting their location to seeing what was available, booking, paying, managing upcoming visits, giving feedback and getting support.
Next.js website
Where people landed from Google or an ad. City, service, cook and pack pages helped them check that ChefKart covered their area and move towards booking.
Payment application
Took payments and tracked whether each one went through, across different services and types of payment.
Operations dashboard
The internal tool the operations team used to deliver visits, manage cooks, sort out incidents, review payments and keep service details up to date.

My role

More than turning designs into screens

I built across the app, website, payments and operations tools. My part usually started before any code was written, and didn’t end at launch.

Before building
Shaping the feature
Worked with product, design, backend, QA and operations to agree how each flow should work, question confusing steps and spot missing states and what could go wrong.
While building
Building it properly
Turned requirements and designs into working screens, connected them to the APIs, added tracking for key actions and tested them.
After launch
Making it hold up
Kept refining the experience and fixed issues as they came up in production.

A small Indian product team reviewing app wireframes on a monitor in a bright office — Much of the work happens before the first component is written

What I took care of in every feature

Reusable building blocks instead of copying the same flow twice
Connecting several backend and third-party APIs
Keeping what the server knows and what the screen shows in sync
Fast loading, and pages that feel quick while they load
Payments and network calls that don’t return a clear answer
Responsive, accessible screens
Tracking important actions and failures
Keeping the same promise across the website and the app
Tools for customers and for the internal operations team

Case study 1 · Payments

One payment layer for every service

Almost every ChefKart service takes money. I built the shared payment layer they all use, including Quick Buy, and designed it so an unclear payment isn’t shown as failed before the server confirms it.

The problem

Customers paid for one-time bookings, Book by Dish, party bookings, packs, remaining balances, wallet top-ups and cook tips.

If every service handled payments its own way, the experience would feel inconsistent and failures would be harder to control. UPI adds a twist: what the payment app reports back isn’t always the final word on whether money actually moved.

What I built

A reusable React Native payment layer that every service plugs into:

Quick Buy, using the payment methods Razorpay recommends for each customer
A direct handoff to UPI apps, with Razorpay’s standard checkout as the fallback
Shared building blocks: method picker, footer, pay button, loading, progress and failure screens
One gateway layer for the different ways a payment can run
Wallet balance, transactions, top-ups, cashback and promo cash, with wallet and online payment shown side by side
Protection against double payments and rapid repeat taps
Checking with the server when a result is unclear, plus clean handling of cancellations and errors
Analytics on every payment step and failure, and automated tests for the critical payment code

Wallet, cashback nudge, payment methods and the three ways a payment can endIllustration, not a real ChefKart screen

The key decision: don’t call it “failed” too early

A UPI app can finish a payment after the customer has already come back to ChefKart. So when it returns an unclear error, showing “Payment failed” straight away might be wrong, and could push someone to pay twice.

The app sorts every response first. It’s a small UX difference with real money behind it: payment screens have to be designed around uncertainty, not just the happy path.

Clear successConfirm the booking
Unclear resultAsk the server for the real status, then decide
Clear cancel or errorReturn to checkout so they can try again

Extra reliability work

I reviewed the whole payment flow and wrote down the risks: duplicate orders, UPI success arriving late, the app resuming mid-payment, repeated requests, pending states, verification and logging. That led to focused tests for polling, locking, analytics, error handling, amounts, Razorpay calls and Quick Buy preloading.

Size of the work

Quick Buy integration
110 files
+9,431 lines added · −3,486 removed
Wallet
116 files
+4,957 lines added · −542 removed
Cashback
84 files
+3,614 lines added · −165 removed

What this shows

Reusable architecture, third-party payment integration, careful failure handling, state management, observability, and working on a product where mistakes cost real money.

Case study 2 · Book by Dish

Booking a cook by choosing the dish

Some customers knew what they wanted to eat before they knew which service to book. I built Book by Dish end to end, from finding a dish to paying and following the visit.

The problem

Inside the app, people didn’t always start with a service type. Sometimes they started with a dish they were craving. Book by Dish had to turn that into a full booking: finding dishes, choosing them, seeing the price for their area, checking a cook was available, picking a time, paying and following the visit afterwards.

What I built

Ways to find dishes on the home screen: offers, popular dishes and curated collections
Browsing by category and cuisine, forgiving dish search, filters and dietary preferences
Dish details, quantity controls, a cart and prices that change by area
Choosing a location, date and time, a booking summary, coupons and offers
Payment, plus screens for an active visit and after the booking

A phone showing a grid of dishes above a table of home-cooked North Indian food: paneer, dal, rice, rotis, sabzi and raita — Book by Dish starts with the meal, not the service type

The key decision: show the menu instantly, update it quietly

The dish catalogue is large, and downloading it every time the app opens would make returning customers wait. So the app keeps a saved copy and checks a small version number in the background to see whether anything changed.

It also ignores repeat refreshes when someone quickly switches in and out of the app, so the same request is never sent twice.

Nothing changedShow the saved menu straight away, no download
Menu updated, or nothing saved yetDownload the full menu once, then save it
No internetKeep showing the last good menu
Saved copy is damagedThrow it away and fetch a fresh one

Size of the work

Initial feature
147 files
+14,826 lines added · −452 removed

What this shows

End-to-end product ownership, Redux and saved-state design, search and catalogue screens, performance thinking, working offline, and connecting one feature across the whole booking flow.

Case study 3 · City pages

City pages that lead to a real booking

People searching for a cook in their city often met ChefKart on the website first. I built city pages that work for search and stay connected to live availability, slots and prices.

The problem

Someone searching for “cooks in Gurugram” might find ChefKart on the web before ever opening the app. For them, a city page couldn’t just be an article written for Google. They wanted to know whether ChefKart covered their area, what they could book, when, and for how much. So the pages had to bring in search traffic and show live booking information at the same time.

What I built

A page for every city, rendered on the server
City content, service areas, live availability, hourly slots and prices
Packs, popular dishes, cuisines, featured cooks, reviews and FAQs
A city directory, location picker, layouts for every screen size and a booking button that stays in view
Tracking for city, slot and pack taps, SEO support and fallbacks when something is missing

Content is cached on the server; availability, prices and booking stay liveIllustration, not a real ChefKart screen

The key decision: cache the content, never the promise

Some things on the page rarely change: city content, cuisines, FAQs, popular dishes and reviews. A small server-side cache keeps those. When lots of visitors arrive at once, they share one request instead of all hitting the backend.

Availability and prices always come fresh. Out-of-date text is a small annoyance; an out-of-date price or slot is a broken promise to a customer.

City content, FAQs and reviewsCached on the server and shared by every visitor
Availability, slots and pricesAlways fetched live, never cached
A request that failsThrown away, so a failure is never saved

Loading everything at once, not one by one

The page needs data from many separate sources. Instead of waiting for each in turn, everything that doesn’t depend on something else starts together: navigation, content, packs, the city itself, dishes, cuisines, FAQs, reviews and occasions. Once the city is known, availability, live slots, areas and featured cooks load together too.

Failing gracefully

If an optional section fails, it falls back quietly and the rest of the page keeps working, while serious failures stay visible. The page also tells apart three different situations: a real city ChefKart doesn’t serve yet, a link that doesn’t exist, and a problem on the server.

Size of the work

City pages, first version
188 files
+14,739 lines added · −324 removed
Live city data and booking
78 files
+5,139 lines added · −801 removed
Responsive location picker
55 files
+1,837 lines added · −404 removed

What this shows

Next.js server rendering, coordinating many APIs, a careful caching strategy, performance work, keeping failures contained, and SEO-aware pages connected to live bookings.

Case study 4 · Cooks Near Me

Helping people choose the right cook

Some customers wanted to pick a cook first, not a service. On the website, I worked on the Cooks Near Me listing and the cook profiles behind it, building on the original pages.

The problem

Letting someone cook in your kitchen takes trust. Before booking, a visitor wants to know what each cook makes, whether they cover the area, how experienced they are, what other customers thought and what it costs. The app had its own way of finding a cook, so these pages were for people who started on the website.

What I built

Search and filters to narrow down the list
Each cook’s cuisines and the areas they serve
Experience, ratings and customer feedback, so visitors can trust who they pick
Clear prices, with API and page caching behind them
Layouts for every screen size, with a clear way to start a booking

Search and filter the list, then open a profile to see who you’re bookingIllustration, not a real ChefKart screen

Size of the work

Listing and profile redesign
67 files
+4,198 lines added · −2,481 removed

What this shows

Designing for trust, presenting a lot of detail clearly, search and filter UX, caching, and turning browsing into a booking.

Case study 5 · Party bookings

Party bookings, start to finish

A party is much more than a regular cook visit. I worked on the screens that let customers plan one, pay for it in parts and change it later, and on the view the operations team used to deliver it.

Why parties are harder

A customer chooses a whole menu, edits dishes and shares food preferences and instructions. They need to know which ingredients and equipment to have ready. Payment is split into an advance and a remaining amount, and the booking still has to work when extra charges come up or plans change after paying.

What I built

Editing the menu and dishes, with ingredient and equipment details
Food preferences and instructions for the cook
Price and payment summaries, with the advance and the remaining amount
Extra charges, and the details shown after paying
Cancellation and refund states
Feedback and ratings for the cook

The customer plans and pays; the operations team sees the same bookingIllustration, not a real ChefKart screen

Connecting both sides

I also worked on the matching part of the operations dashboard, so everything the customer set up reached the team who had to deliver the party.

What this shows

Handling complex booking flows, payments in parts, changes after payment, and keeping the customer app and the operations dashboard in step.

Case study 6 · Operations tools

Tools for the team behind every visit

Customers only see half of a service business. The operations team needed their own tools to run visits, look after cooks, handle problems and keep the menu up to date, and I worked on many parts of the dashboard they used every day.

Why it mattered

Every booking a customer made became work for someone. The operations team needed to see every visit, the cooks, incidents, payments, the dish catalogue and anything that went wrong, in one place.

Tracking visits

A list of every visit, with a detail page for each
Filters by status, a colour key and a timeline of what happened
Links to the related booking, plus technical details for troubleshooting

Visit statuses, a visit timeline and an incident alert in one viewIllustration, not a real ChefKart screen

Handling emergencies (SOS)

A list of alerts, with details and status updates
Comments, timestamps and filters
Links to related records, and shared reference tables for alert types

Managing cooks

Reasons, and sub-reasons, when a cook turns down a visit
Leave and penalties, and undoing a denied visit
Freeing up upcoming slots, filtering by several times, and controls for availability and wallet limits

Dishes, offers and payouts

Managing cuisines, dishes and ingredients, with image upload, preview and verification
More options for coupons and packs
Vendor payout references, and a view of payments and cancellations

Size of the work

My code still in the dashboard
17,124 lines
About 11.72% of its current source
First version of visit tracking
13 files
+2,496 lines added · −570 removed

What this shows

Understanding the business beyond the customer app, and turning day-to-day operations into internal software that is clear and consistent to use. Internal tools are described at a general level; no internal screens or data are shown.

Breadth of work

Everything I worked on, at a glance

The case studies above go deep on a few features. This is the full range, grouped by the product it belongs to.

Customer app

19 areas

Starting in the app
Onboarding
Phone number and OTP autofill
Choosing a location
Checking area and availability
Finding a service
Payments
Wallet
Cashback
Book by Dish
Party booking
Packs and coupons
Changing cooks
Visit details
Ratings and feedback
Help and FAQs
Analytics
Over-the-air app updates
App stability

Customer website

14 areas

Visitors from Google search and ads
City pages
Cooks Near Me
Choosing a location
Area check
Live booking slots
Packs
Campaign pages
Booking summaries
A booking button that stays in view
City directory
SEO support
Layouts for every screen size
Analytics

Operations dashboard

10 areas

Visit tracking
SOS alerts
Party operations
Cook availability
Penalties and leave
Dishes and cuisines
Coupons
Vendor payouts
Payment tracking
Customer and address search

Engineering

How I make engineering decisions

The habits behind the case studies above, in plain words.

Start with what could go wrong for the customer
The simplest thing to build isn’t always the honest one. In payments, availability, pricing and delivery, showing the wrong state costs real money and trust.
Build it once where it must behave the same
Payment screens, booking summaries, status labels and shared operations views work best as common components with clear rules, so they behave the same everywhere.
Don’t make work wait for no reason
If two requests don’t depend on each other, neither should wait for the other. This shaped how the city pages load on the server.
Cache what’s stable, keep prices and slots live
Content, menus, prices and availability go out of date at different speeds. Treating them the same either wastes resources or makes promises that are no longer true.
Plan for things going wrong
Losing the internet, an unclear payment, a missing section, an unsupported city, a slow API, a retry or a cancellation are all part of the experience, so each one needs proper handling.
Design for every way in, not one perfect path
A website visitor, a new app user and a returning customer start with different context. Good architecture respects that while keeping booking, payment and delivery the same for everyone.
Know what happens after the button is pressed
Working on the operations tools gave me a clearer picture of delivery, incident response and support, and that made my customer screens better.

Contribution

Contribution evidence

Where my code stands today in each of ChefKart’s four repositories.

React Native app
#1of 18 current contributors
Ownership35.05%
surviving lines
62,595
authored commits
240
Customer website
#1of 13 current contributors
Ownership33.18%
surviving lines
27,450
authored commits
70
Operations dashboard
17,124surviving lines
Ownership11.72%
authored commits
143
Payment application
625surviving lines
authored commits
8

Across all four

461
Authored commits across four repositories
107,794
Currently surviving source lines
1,065
Distinct files introduced across the three main products

How this was measured

Current ownership was calculated with git blame on the development branches across non-blank TypeScript, JavaScript, React, CSS, SCSS and HTML source lines. Generated and vendor code was excluded, and multiple Git identities belonging to the same developer were consolidated. These numbers measure current surviving source ownership, not every line ever added. They are supporting evidence of scope; the product journeys and engineering decisions above are the more important measure of the work.

What I bring

What I bring to a team

What the work above adds up to, for the team I join next.

Ownership across multiple customer entry paths and complete service journeys
Strong React Native, React, Next.js and TypeScript execution
Product thinking alongside frontend engineering
Experience with payments and operationally sensitive workflows
Performance, caching and resilience thinking
Ability to work across customer and internal products
Clear collaboration with product, design, backend, QA and operations
A habit of improving features after their first release

In my words

The work I am proudest of is not a single component or a large commit. It is following a real customer problem, whether it begins on the website or inside the app, carrying it across booking and payment, understanding the operational consequences, and building a solution that stays reliable outside the happy path.

FAQ

Quick answers about my ChefKart work

The short version: my role, what I built, how much of the code is mine and whether I’m open to new roles.

I’m an Associate Software Engineer, working there since December 2025. I build the customer app, the website, the payment application and the dashboard the operations team uses every day.

Six pieces of work are covered on this page: the payment layer every service uses (including Quick Buy), Book by Dish, city pages, Cooks Near Me, party bookings and the operations team’s tools.

React Native for the app, Next.js and React for the website and dashboard, and TypeScript throughout. Also Redux, Razorpay, server-side rendering, REST APIs, caching and analytics.

No. I also handle what happens when things go wrong, such as an unclear payment, no internet or a failed request. I make caching and rendering decisions too, and build tools for the operations team.

I’m the #1 contributor on both the app (out of 18) and the website (out of 13). Across four repositories, that’s 461 commits and 107,794 lines of my code still in use. The Contribution section shows how this was measured.

Yes. I’m based in Gurugram, Haryana, and open to frontend and React Native opportunities where I can own a product journey from start to finish.

I want to build products that customers depend on

I’m looking for frontend and React Native opportunities where I can take meaningful product ownership, collaborate closely with product and design, and help build experiences customers use every day.

Let’s talk View my résumé

Building every path into a ChefKart booking and the systems that fulfil it

I helped build these customer paths and the operational systems behind them across ChefKart’s React Native app, Next.js website, payment application and internal operations dashboard.

Gurugram · Onsite · December 2025 – Present

React Native · Next.js · TypeScript · Redux · Razorpay · SSR · REST APIs

Three ways people booked a home cook

Through a Google search

Straight from the app

Coming back to book again

After booking, the journey is the same

The four products behind every booking

React Native app

Next.js website

Payment application

Operations dashboard

More than turning designs into screens

Shaping the feature

Building it properly

Making it hold up

What I took care of in every feature

One payment layer for every service

The problem

What I built

The key decision: don’t call it “failed” too early

Extra reliability work

Booking a cook by choosing the dish

The problem

What I built

The key decision: show the menu instantly, update it quietly

City pages that lead to a real booking

The problem

What I built

The key decision: cache the content, never the promise

Loading everything at once, not one by one

Failing gracefully

Helping people choose the right cook

The problem

What I built

Party bookings, start to finish

Why parties are harder

What I built

Connecting both sides

Tools for the team behind every visit

Why it mattered

Tracking visits

Handling emergencies (SOS)

Managing cooks

Dishes, offers and payouts

Everything I worked on, at a glance

Customer app

Customer website

Operations dashboard

How I make engineering decisions

Start with what could go wrong for the customer

Build it once where it must behave the same

Don’t make work wait for no reason

Cache what’s stable, keep prices and slots live

Plan for things going wrong

Design for every way in, not one perfect path

Know what happens after the button is pressed

Contribution evidence

React Native app

Customer website

Operations dashboard

Payment application

What I bring to a team

Quick answers about my ChefKart work

What is your role at ChefKart?

What have you built there?

Which technologies do you work with?

Is it only front-end screens?

How much of the code is yours?

Are you open to new opportunities?

I want to build products that customers depend on

Three ways people booked a home cook

Through a Google search

Straight from the app

Coming back to book again

After booking, the journey is the same

The four products behind every booking

React Native app

Next.js website

Payment application

Operations dashboard

More than turning designs into screens