Hop Orbits

A multi-vendor marketplace for Lahore, co-founded and architected by me — which means this case study is written from the least comfortable and most instructive seat in software: the person who both designed the system and carried the business consequences of every technical decision. A marketplace is really four products shipped at once: a buyer-facing catalogue, a seller portal for listings and order management, a payments and escrow layer that both sides can trust, and the real-time messaging where the actual commerce happens. Startup timelines don't let you build them sequentially.

The platform launched, onboarded an initial base of merchants and buyers, and ran its listings, orders, and live conversations without falling over. The venture was later wound down — not because the technology failed, but because the co-founders' priorities moved on. The honest summary: the engineering proved itself; the business was shelved. Both halves of that sentence belong in a case study.

The backend is Java / Spring Boot organized into cleanly separated modules — listings, orders, messaging, payments — a microservices-inspired shape without the operational cost of actual microservices, which a two-person startup has no business paying. Each module owns its domain and could have been split out into a service later if scale had demanded it; none ever needed to be, which is its own architectural lesson. Buyer and seller Android apps share one common API layer, so every feature shipped once and served both sides of the market.

Real-time chat runs over WebSockets rather than polling, and in a marketplace that choice is commercial, not cosmetic: negotiation is the product. A buyer haggling over price abandons the conversation if messages take seconds to arrive; a persistent socket makes the exchange feel like messaging apps users already trust. The messaging module handled concurrent conversations alongside live order traffic — the load profile that makes marketplaces harder than catalogues.

Three lessons that now inform client work. First, module boundaries are cheap insurance: the clean listings/orders/messaging/payments separation meant every pivot discussion was a scoping exercise, never a rewrite threat. Second, the operational half of a marketplace — merchant onboarding, dispute handling, payment reconciliation — costs as much as the software half, and any client building a two-sided platform should budget accordingly; I say this now with a founder's receipts. Third, real-time infrastructure is worth its complexity exactly where conversation is revenue, and nowhere else.

For prospective clients the relevant fact is this: I have built a multi-vendor marketplace end to end — both apps, the backend, the payments layer, the live messaging — and operated it in production with real merchants and real money. That experience is rarer than marketplace pitch decks suggest, and it transfers whole to the next platform of this shape.