Zippi

1. Overview

1.1 Purpose

Zippi is a single app for two everyday needs — shopping and getting around. Customers browse multi-vendor product catalogues, pay securely and track delivery, and in the same app book a bike, auto or cab with live driver tracking. Behind them, vendors manage products, stock, orders and discounts; drivers accept deliveries and rides and track earnings; and an admin oversees vendors, drivers, payments, disputes, promotions and reporting. This document covers all four surfaces.

1.2 Product vision

One trusted app that moves both goods and people — combining a multi-vendor marketplace and an on-demand ride network on a shared payments, wallet, notifications and identity layer, so every customer, vendor and driver lives in one ecosystem.

1.3 Surfaces

Four products ship together: the Customer app (shop + ride), the Vendor dashboard (web), the Driver app (deliveries + rides), and the Admin panel (web) with full operational control.

1.4 Scope

In scope: OTP/social auth; multi-vendor catalogue, cart, checkout & delivery tracking with OTP; ride booking, driver matching & live tracking; wallet, coupons & loyalty; ratings/reviews; vendor product/stock/order management; driver job management & earnings; the admin panel; and the platform's security, DevOps, infra and analytics posture. Payments via gateway + wallet.

2. User Personas

3. Functional Modules

The platform is built from shared modules across the four surfaces:

4. E-Commerce User Journey

The shopping flow is end-to-end: onboarding (register, verify phone/email); discovery (categories, search, filter, sort); product detail (photos, price, specs, reviews, variants); cart (quantities, coupon codes, delivery estimate); checkout (addresses, payment method, confirm); order tracking (live status, contact support); delivery (OTP verification on hand-over, review the driver, download invoice); and post-order (returns, refunds, issue reporting, rating). See the shop flow play out in the demo →

5. Transportation User Journey

The ride flow mirrors it for mobility: onboarding (register, KYC, vehicle-type preference); booking (pick pickup/drop on the map, fare estimate, choose vehicle type — bike / auto / cab); confirm (payment method, coupon, confirm); ride progress (live driver location, ETA updates, SOS button); end of ride (fare summary, invoice, review); and ride history (past bookings, receipts, issues).

6. Order & Booking Lifecycle

Each transition is event-driven, pushes a notification to the customer, and is reflected on the driver, vendor and admin surfaces in real time.

7. Vendor Dashboard

Vendors run their store from a web dashboard: add & maintain products (photos, specs, variants, price), manage stock & availability, accept/reject & fulfil orders (pack → dispatch), set store discounts & coupons, and view earnings & settlement reports. Onboarding requires KYC and admin approval before a store goes live.

8. Driver App

Drivers work both networks from one app: go online, receive delivery or ride requests, accept or reject, navigate to pickup/drop, and advance the job through its status (Assigned → Picked up → On trip / Out for delivery → Completed), verifying delivery with the customer's OTP. They track earnings by day/week and manage vehicle & KYC documents.

9. Admin Panel

The admin panel is the operations command centre with role-based permissions: vendor approval, driver/KYC approval, order & booking oversight and override, refund handling, dispute resolution, commission & payment reconciliation, promotions, broadcast notifications, and reporting dashboards with exports and audit logs.

10. Payments & Wallet

A shared money layer spans commerce and mobility: a payment gateway (UPI / card / netbanking), an in-app wallet (top-up, pay, refunds), coupons & loyalty, commission splits to vendors and drivers, and surge pricing for rides. All flows are reconciled and invoiced, with refunds handled from the admin panel.

11. Security Architecture (OWASP Top 10)

12. DevOps & CI/CD

Development runs on GitHub (the client is invited as a collaborator to review code), with a clear PR/merge strategy and protected branches. GitHub Actions pipelines run unit, integration and E2E tests, build Docker images to a registry, and auto-deploy the whole platform to AWS — blue-green / canary releases with automated alerts and rollbacks.

13. Infrastructure, Scale & DR

Infra: managed Kubernetes (EKS) with VPC isolation, auto-scaling groups, NGINX ingress load balancing, database failover, and S3 for static/media. Scale & HA: read replicas, partitioning/sharding, CDN, Redis caching, and queue-based background jobs. Disaster recovery: defined RTO/RPO targets, automated backup snapshots, a failover strategy and an emergency contact tree.

14. Analytics & Monetization

Analytics: KPIs for orders, rides, refunds, top sellers, customer churn, delivery SLAs and sales trends with seasonal breakdowns. Monetization: vendor & driver commission structures, platform fees, promotions & upsell campaigns, and surge pricing for transport — all configurable from the admin panel.

15. Compliance, Testing & Support

Compliance: GDPR & data-retention policy, cookie policy, PCI-DSS-aligned payments, KYC for driver onboarding, and clear refund policies. Testing: a test-case matrix spanning UAT, regression, performance and security testing. Support & delivery: 12 months of maintenance, full handover documentation, vendor-team training and a helpdesk setup.

16. Open Questions

1. Database — MongoDB vs PostgreSQL (or both: Postgres for transactions, Mongo for catalogue/geo)?
2. Launch cities & categories — which product categories and which ride vehicle types at launch?
3. Payments & escrow — gateway choice, wallet KYC limits, and payout cadence to vendors/drivers.
4. Maps & matching — provider (Google/Mapbox) and the driver-matching & surge algorithms.
5. Delivery model — platform drivers only, or vendor-arranged + 3PL for commerce orders?
6. Phasing — ship commerce first, mobility second, or both together for the MVP?