◀ ARCHIVE_RECORDS / PROOF_OF_WORK
CASE_FILE: 001 // STATUS: OPERATIONALCLASSIFICATION: Marketplace_Platform

Studeaze

Quick-commerce marketplace for study materials

CLIENT
Studeaze (ACUMNX Solutions Pvt. Ltd.) — Nashik, Pune & expanding across Maharashtra
PLATFORM
Web — Next.js storefronts, NestJS API, Supabase Postgres
STACK
Next.js · NestJS · Supabase · Razorpay · Porter
SECTION_01

The Challenge

Studeaze had a working product vision and early traction — a zone-aware marketplace connecting students to nearby bookstores — but the legacy React + Spring Boot + MongoDB stack was blocking scale:

GAP_01

Legacy stack drag

A React/Vite SPA over Spring Boot and MongoDB — hard to hire for, slow to ship, and costly to operate at marketplace scale.

GAP_02

Undocumented domain logic

Zone routing, stock reservation, seller assignment, and payment recovery lived across services with limited handover.

GAP_03

Money + inventory together

Checkout must be atomic: reserve stock, create order, take payment, and recover cleanly on failure — or two buyers purchase the last unit.

GAP_04

Zone-aware quick commerce

Cities split into delivery zones; orders must prefer the buyer's zone and fall back to the nearest seller with full cart availability.

GAP_05

No clean delivery API

Porter exposes no public booking API for this use case — last-mile automation required browser sessions, OTP handoff, and anti-bot workarounds.

GAP_06

Indian-language catalog

Thousands of Marathi/Hindi titles in Devanagari script were invisible to Latin-script search queries.

SECTION_02

Our Approach

MOD_01

Audit first, rebuild second

Not a line-by-line port — a spec-driven rebuild. The legacy Spring Boot app and Mongo schema were treated as the source of truth, not the implementation to copy: APIs, order lifecycle, zone rules, and catalog shapes mapped before code, with payments made server-authoritative and internal runbooks produced.

MOD_02

Monorepo with clear boundaries

One repo, shared conventions, independent deploys — Vercel for frontends, Render/Railway for the API and delivery worker.

  • Customer storefront — mobile-first catalog, zone-aware delivery messaging, SecuRe Buy & Smart Save modes, Notify Me demand signals
  • Seller portal — approval-gated onboarding, stock & pricing tools, realtime orders, Porter booking widget, settlements panel
  • Admin ops — seller review, books explorer, refunds queue, coupons, analytics dashboard
  • NestJS API — orders, payments, zones, inventory, assignment, Porter delegation
  • Porter worker + internal Docusaurus docs site
MOD_03

Postgres as the system of record

Business invariants moved into the database where possible.

  • Atomic checkout RPCs — reserve stock, attach Razorpay order id, confirm or fail payment in single transactions
  • Full-text + trigram search with weighted tsvector and typo tolerance
  • Native-script columns preserve Devanagari while Roman transliterations power Latin queries
  • Zone assignment: buyer zone match → nearest seller with full line availability → controlled fallback
  • RLS and triggers — sellers cannot self-approve; facets rebuild on catalog writes
MOD_04

Payments you can trust

A SQL RPC pipeline (reserve stock → set Razorpay order id → confirm or release), HMAC verification on callbacks and webhooks, server-side amount verification against the Razorpay API, and a reconciliation cron for orders stuck mid-checkout.

MOD_05

Delivery automation without an API

Porter's booking UI requires an authenticated browser session, Google autocomplete, OTP, and anti-bot protections. We built a dedicated Playwright booking worker with persisted auth state, Google Places alignment, an OTP relay endpoint for sellers, video capture per run, and proxy support — decoupled from the main API so booking failures never take down checkout.

MOD_06

Data platform & catalog quality

Repeatable Mongo → Postgres ETL preserving nested JSONB, canonical inventory split from per-seller offers, a multi-source cover repair pipeline for broken legacy CDN URLs, and Gemini-powered Devanagari transliteration (~2,600 titles) — all encoded in 160+ versioned SQL migrations.

SECTION_03

Technical Highlights

Storefronts
Next.js (App Router), React, TypeScript, Tailwind, shadcn/ui
API
NestJS — structured validation, modular domains
Database
Supabase Postgres — RLS, SQL functions, Realtime; 160+ versioned migrations
Auth & SMS
Supabase Auth (phone OTP) with Fast2SMS edge hook
Payments
Razorpay — orders, verify, webhooks, reconciliation cron
Delivery
Porter via Playwright booking worker + seller widget
Search
Postgres FTS + pg_trgm + prefix typeahead RPCs, dual-script indexing
Observability
Sentry, Pino (PII redaction), PostHog, GA4
SECTION_04

Outcomes

  • 4 production apps shipped — storefront, seller portal, admin ops, API — plus Porter worker and docs site
  • 8,000+ canonical catalog rows across engineering, K–12, competitive exams, and stationery
  • 2,631 Devanagari titles preserved and transliterated for Latin-script search
  • End-to-end payment path with atomic stock reservation, webhook verification, and reconciliation
  • Seller self-service: stock, orders, Porter booking, settlements, and demand notifications
  • 160+ SQL migrations encoding domain rules beside application code
MISSION_DEBRIEF

Studeaze needed more than a stack migration — they needed a platform they could own and extend. We rebuilt a legacy React + Spring Boot + MongoDB marketplace into a modern monorepo with database-enforced invariants, trustworthy payments, zone-aware fulfillment, and delivery automation where no API existed — keeping students, sellers, and admins on one schema and one migration history.

— END_OF_CASE_FILE_001