Koor Food Delivery

What is Koor?

Koor is a marketplace for home-cooked food. Its Google Play listing sets out three groups of users. Customers browse homemade dishes, from daily meals to sweets and cakes, place orders and track them live from preparation to delivery. Home chefs and bakers create a profile, upload their dishes, set prices, promotions and availability, and manage orders as they arrive. Riders accept deliveries, see pickup and drop-off locations, and keep track of their completed deliveries and earnings.

The proposition is narrow on purpose: homemade food only, not restaurant takeaway. That narrowness is what shapes the engineering, because supply that comes from home kitchens behaves very differently from supply that comes from restaurants.

What did Sameem work on?

Sameem worked on Koor, a product whose client is not named here. It is a React Native mobile app on a NestJS backend. Firebase carries real-time order and delivery updates, Elasticsearch powers search across chefs and dishes, and the system runs on AWS, using EC2 for the application servers, S3 for storage and CloudFront for content delivery.

The sections below explain why each part of that stack suits a home-chef marketplace and what each part has to get right.

Why is discovery the hard problem in a home-chef marketplace?

Ordering online is a solved problem for restaurants. It is not solved for home cooking. Restaurant supply is stable, standardised and well documented: fixed menus, fixed hours, a known address. Home-chef supply is fragmented, personal and constantly changing. A chef may cook a handful of dishes one day and a different set the next, serve only a small delivery area, and describe their food in regional or colloquial terms that no fixed menu taxonomy anticipates.

That makes discovery, not checkout, the hard engineering problem. A customer has to be able to find a dish that exists today, from a chef who is cooking today, close enough to arrive hot. A home-chef marketplace has to make an unstructured, fast-changing supply feel as searchable and as dependable as a chain restaurant's menu.

The rest of the stack follows from that. Search needs its own engine, order status needs a live channel, and food photography, which is how people choose what to eat, needs storage and delivery that do not slow the app down.

Why React Native for the Koor app?

The Koor app is written in React Native. The framework suits a marketplace whose interface is mostly lists, cards, photos and status screens: browsing chefs, reading a dish's details, following an order. React Native renders those through real native views rather than a web page inside an app shell.

The listing's own permissions show why native access matters. It asks for location, to detect the delivery address and track orders; notifications, to report each stage of an order; and camera and storage, so chefs can upload food photos and users can add profile pictures. React Native reaches each of those through native modules while the product screens stay in the JavaScript layer, where they can be changed quickly as the marketplace changes.

The commercial argument is reach per line of code. One codebase can produce both an Android and an iOS build, so adding a platform becomes a release decision rather than a second app to build and maintain.

Why NestJS for the marketplace backend?

A food marketplace has several distinct domains: identity, chef onboarding, the dish catalogue, pricing and promotions, ordering, delivery tracking and notifications. NestJS gives each of those its own module, with explicit providers and dependency injection, so the boundaries between them are enforced by the framework rather than left to convention. Ordering code cannot quietly reach into search or notification internals.

NestJS is TypeScript-first, which matters when a mobile app and an API have to agree on what an order looks like. When both sides share the same type definitions, a mismatch between the app and the server shows up as a compile error instead of a bug in production.

Its guards, pipes and interceptors map cleanly to what this kind of product needs: separating what customers, chefs and riders are each allowed to do, validating every incoming order before it is stored, and returning errors in a consistent shape. Keeping Elasticsearch and Firebase behind injectable services, rather than calling their SDKs from all over the codebase, also means either can be replaced without rewriting the order logic.

What does Elasticsearch add to dish search?

A relational LIKE query cannot cope with the way people search for homemade food. They use regional dish names, transliterations, alternate spellings and ingredient words rather than category names. Elasticsearch handles that variation with analyzers, synonyms and fuzzy matching, so a misspelt or colloquial query can still reach the right chef.

Relevance here has more than one dimension. A result is only useful if the dish matches what the customer wants, the chef is currently taking orders, and the kitchen is close enough to deliver. Elasticsearch can combine full-text scoring with geo-distance and availability filters in a single query, which is what turns a list of matches into a list of dishes someone can actually order.

The usual way to run it is as a read-optimised copy of the marketplace data, not as the source of truth. In that setup, chef and dish changes are indexed into Elasticsearch as they happen, so browsing stays fast without adding load to the database that records orders.

How does live order tracking work with Firebase?

The Koor listing offers customers live tracking of an order from preparation to delivery, and real-time updates for chefs and riders. Firebase is the part of the stack that carries those updates.

Polling an API every few seconds for order status is wasteful on a phone. It drains the battery, uses mobile data and still shows stale status between requests. A push model inverts that. The app subscribes once and each change of state, such as accepted by the chef, being prepared, picked up or out for delivery, arrives over an open connection, so the screen updates when the event happens rather than on the next poll.

Firebase also covers the moments when the app is closed, through push notifications for the stages a customer actually cares about. Its SDKs on the phone can also keep the last known state when a phone loses signal and catch up when the connection returns, which matters for an app that riders use on the move.

What does AWS do in this setup?

Koor runs on AWS, using EC2, S3 and CloudFront. EC2 runs the NestJS application servers. Food delivery demand is never flat: it concentrates around lunch and dinner, so being able to add compute for predictable peaks, instead of paying for peak capacity all day, is both a reliability decision and a cost decision.

S3 holds the media. A home-chef marketplace is driven by photography, because people order food they can see. Storing each upload as an object in S3, rather than as a file on an application server, keeps those servers stateless and therefore easy to replace or add to.

CloudFront then serves that imagery from edge locations close to the user. Dish photos are the heaviest thing the app downloads, and caching them near the customer is what keeps a scroll-heavy browsing experience quick on mobile networks.

What engineering problems does a delivery marketplace raise?

Three constraints shape a platform of this kind, and they pull against each other.

The first is concurrency. An order is a state machine that the customer, the chef and the rider all touch, and every transition has to be applied exactly once. If a status update arrives twice, or two parties act at the same moment, the order must still end up in one correct state. The standard answer is to keep authoritative writes on the server, behind one service layer, rather than letting each app write order state directly.

The second is freshness. Availability changes constantly as chefs open, close and sell out, so the search index has to follow the order database closely enough that customers are not offered food nobody is cooking.

The third is uneven load. Browsing, image delivery and checkout grow at different rates and peak at different times of day. Splitting them across Elasticsearch, CloudFront and the application servers is what lets each be scaled and tuned on its own terms.

Where can you see Koor?

The Koor app is on Google Play as Koor Homemade Food & Delivery, under the package com.koor_user and the developer name KOOR homemade foods & deliveries. It was first released there in October 2025, and the listing sets out the customer, home-chef and rider features covered above. The Google Play listing is the place to see the product as it ships today.

Why this stack

• React Native: the framework the Koor app is written in. An app made of lists, cards, photos and status screens renders well through React Native's native views, and the framework reaches the native features the listing asks for (location, notifications, camera and storage) through native modules. One codebase can target both Android and iOS, so a second platform is a release decision rather than a second app.
• NestJS: a food marketplace splits into identity, chef onboarding, catalogue, pricing, ordering, delivery tracking and notifications, and NestJS enforces that split with modules, explicit providers and dependency injection instead of leaving it to convention. Being TypeScript-first lets the API and the app share type definitions, so a contract mismatch fails at compile time, and its guards, pipes and interceptors cover role separation between customers, chefs and riders, payload validation and consistent errors.
• Elasticsearch: homemade dishes are searched for in colloquial, regional and transliterated language that a SQL LIKE query cannot handle. Analyzers, synonyms and fuzzy matching absorb that variation, and combining full-text scoring with geo-distance and availability filters in one query returns dishes that are both relevant and orderable. Running search on a read-optimised index keeps browsing load off the order database.
• Firebase: order status is a stream of events, not a record to poll. A subscription model updates the screen when a stage changes, saves battery and mobile data, reaches people through push notifications when the app is closed, and copes better when a phone loses signal mid-delivery.
• AWS EC2: delivery demand peaks around mealtimes, so running the NestJS servers on elastic compute lets capacity follow those peaks instead of being provisioned for the busiest hour all day.
• AWS S3: chef and dish photos are user uploads; storing them as objects keeps the application servers stateless and replaceable, which is what makes adding servers straightforward.
• AWS CloudFront: dish photos are the heaviest payload in the app, so serving them from edge caches keeps browsing quick on mobile networks instead of waiting on the origin servers.