Built in-house

Engineering built to scale, not rebuilt to survive it.

Quickeee runs on systems we wrote ourselves: order dispatch, delivery-zone routing, live merchandising and a reliability layer designed around failure. That is why more brands, more stock and more kilometres do not turn into cost for the people selling with us.

See the four systemsTalk to our team

One dark store. Every address inside the zone. Live.

Nodes = stores · Arcs = routes · Dots = orders

5,000/dayconfirmed order capacityGrowth does not require re-engineering.
99.7%crash-free, zero downtimeNo operational risk sitting on your inventory.
18 kmdelivery radius, up from 10 kmFewer stores per city — more reach from the same stock.
90%manual work removedPricing, onboarding, banners and delivery zones go live without an engineering ticket.

Capacity, crash-free rate, radius and automation figures are Quickeee internal engineering numbers. The 60-minute delivery window is an operational target, not a contractual guarantee — see the Terms of Service.

Anatomy of one order

Six handoffs, none of them manual

An order crosses six systems before it reaches a doorstep. Each handoff is automated end to end — this is the sequence the four systems exist to serve.

  1. 01

    Location resolves into a promise

    One call turns raw coordinates into a pincode, a city, the assigned dark store, whether we can serve that address right now, and the ETA the customer is about to be shown.

  2. 02

    The order binds to a store at checkout

    Fulfilment is decided before payment, not after. If a store is closed or out of zone, the order cannot be placed — we do not accept orders we cannot fulfil.

  3. 03

    Payment confirms against the gateway, not the phone

    The payment webhook is the source of truth. The app polls the order and falls back to an explicit verify call until a final status lands, so a dead battery mid-UPI does not become a lost order.

  4. 04

    Pick and pack inside the packing window

    The packing minutes quoted in the customer's ETA are the same minutes the store is held to. The promise and the operation use one number.

  5. 05

    Handoff to last mile, with live tracking

    Order and address pass to our delivery partner, and rider position flows back into the customer's map for the length of the trip.

  6. 06

    Fit-check at the door, then settlement

    The customer tries the item before paying. What survives the doorstep is a delivered order, reconciled against your payout — not a return three weeks later.

What we built

Four systems, all ours

Not a stack diagram. These are the four things that decide whether an order reaches a customer in under an hour — and every one of them is code we own.

Dispatch01

Automated order-to-store handoff

An order is bound to a specific dark store by software at checkout — not by a human on WhatsApp after the fact.

  • Payment truth comes from the gateway webhook rather than the device. The app polls the order, then falls back to an explicit verify call until it has a final answer.
  • In-progress payments are persisted on the device, so an app kill, a dead battery or a bounced UPI app-switch still resolves to the correct order state.
  • UPI intent, UPI VPA, netbanking, cards, wallet credits and cash on delivery all land in one confirmed-order pipeline — no parallel manual flow per method.
  • Confirmed orders hand off to the last-mile partner automatically, with tracking returned to the customer.
Routing02

Our own delivery-zone algorithm

Coordinates go in. Serviceability, the assigned store and a defensible ETA come out — composed from real parts, not rounded off a guess.

  • A single call resolves latitude and longitude into pincode, city, primary store and a live serviceability verdict — before the customer commits to anything.
  • ETA is composed, not guessed: packing minutes plus driving minutes plus buffer, against a store-level SLA and real road distance.
  • Store open/closed and in-zone flags gate the order at source, which is why the app rarely cancels after the fact.
  • Every ETA is stamped with the source that produced it — live partner telemetry first, then smoothed traffic data, then conservative fallbacks.
  • Widening the radius is a configuration change to the zone model, not a rewrite — which is how 10 km became 18 km.
CMS03

Live pricing and merchandising

The storefront is configuration, not code. Merchandising moves in minutes and never waits on an app release or a store review.

  • The home feed is section-driven: the backend sends the layout, the app renders it from a registry of section types — hero banners, product grids, brand rails and more.
  • Audience personalisation runs through the whole catalog. Men, Women and Kids each get their own category ordering and imagery from the same endpoints.
  • One taxonomy, one source: the seller portal reads the same category tree the buyer app does, so what a brand declares at onboarding cannot drift from what is live in the app.
  • Runtime flags change app behaviour — including which telemetry pipelines are active — without shipping a build.
Reliability04

Self-healing infrastructure

Failure is designed for, so a bad minute stays a bad minute instead of becoming a bad day for everyone's stock.

  • Three independent crash and error pipelines run in parallel, with remote kill switches — a noisy vendor never becomes an emergency app update.
  • Network failures are values, not exceptions. Every API call returns an explicit success or failure result, so a backend hiccup renders as a retry state rather than a crash.
  • Identical in-flight requests are de-duplicated, so fast navigation cannot stampede the API.
  • Auth tokens refresh transparently on expiry and session boot is single-flight — no redirect loops, no surprise logout mid-checkout.
  • Sensitive fields are redacted before anything reaches a log, and API responses are sanitised on the way in.

The stack

Owned where it counts, rented where it does not

Buyer app

Flutter

One codebase shipping to iOS, Android and web. Feature-first clean architecture, Riverpod state, typed models generated from schema.

Seller Hub

Next.js 16 · React 19

The onboarding portal at seller.quickeee.com. TypeScript end to end, design tokens shared with the buyer app, deployed on Vercel.

Core API

NestJS · Prisma

Catalog, orders, payments, location and serviceability. Typed contracts, one schema, one migration path.

Measurement

One event facade

Every event is defined once and fanned out to GA4, Firebase, MoEngage and Meta — with impression and session tracking built in, so funnel data is instrumented at the source rather than reconstructed later.

Bought on purpose

AWS

Mumbai-region hosting

Firebase

OTP auth, push, remote config

PayU

Payment processing

Pidge

Last-mile delivery

Freshchat

Customer support

Google Maps

Geocoding & road data

Commodity infrastructure is rented so our engineers spend their hours on the parts that actually move a brand's sales: routing, merchandising and dispatch.

Security & data

Commitments, not assurances

Everything below is published in the Quickeee Terms of Service and Privacy Policy. It is checkable, which is the point.

Data stays in India

Platform data is held on AWS infrastructure in the Mumbai region.

Encrypted both ways

TLS/SSL in transit, AES-256 for sensitive data at rest, with regular audits.

We never hold card data

Payments run through a PCI-DSS compliant gateway. Full card details are never stored by Quickeee.

Retention is defined

Transactions kept 7 years, account data 3 years after closure, deletion requests processed within 30 days.

Full detail: Terms of Service · Privacy Policy. Data protection contact: privacy@quickeee.in.

Straight answers

The technical questions

No, and we do not claim it is. Our Terms of Service put it plainly: Quickeee aims to deliver every order within 60 minutes of order confirmation, provided the address falls inside an active serviceability zone, and that commitment is an operational target rather than a contractual guarantee. What the technology guarantees is that the ETA shown to a customer is composed from real parts — packing time, driving time and buffer — instead of being a marketing number.

No. There is no API to call, no plugin to install and no inventory feed to maintain. A partner completes the onboarding form, sends agreed stock to the dark store, and everything on this page is our side of the arrangement.

On AWS infrastructure in the Mumbai, India region. Data is encrypted in transit with TLS/SSL and sensitive data at rest with AES-256. Retention periods and the data protection contact are published in the Privacy Policy.

The order still confirms. We treat the payment gateway's webhook as the source of truth rather than the customer's device, and payment state is persisted locally so the app resumes checking when it comes back. Fewer stuck orders, fewer disputed payments against a partner's stock.

ETA sources are graded. Live delivery-partner telemetry is preferred, then a traffic-smoothed road estimate, then a store-level soft estimate, then a conservative fallback. Every ETA is stamped with the source that produced it, so accuracy can be measured per source rather than guessed at.

Quickeee's in-house engineering team. Dispatch, the delivery-zone algorithm, the merchandising CMS and the reliability layer are ours. We deliberately rent commodity infrastructure — cloud hosting, the payment gateway, last-mile delivery, maps and support tooling — and own everything that touches how a brand is sold and delivered.

The expensive part is already built.

Everything on this page is running in production today — not a roadmap. The next city needs stock and riders, not another engineering cycle. That is where the leverage is.

Talk to our team
Quickeee — Fashion. Now.

© 2026 Quickeee. All rights reserved.