The Challenge
Offerly is an internal product by Vista Systech Limited — a reverse-auction mobile marketplace built for the Bangladesh market (৳ BDT), available on both iOS and Android from a single codebase. The product was conceived to fix a fundamental imbalance baked into traditional e-commerce: sellers set the price, and buyers either take it or leave it. In a price-sensitive market like Bangladesh, that dynamic leaves a lot of value on the table for both sides.
The problem space had two distinct, equally broken sides:
Customers had zero pricing leverage. On every existing marketplace, the seller dictates the price. Buyers either accept it, jump between five different apps comparing listings for hours, or give up. There was no mechanism for a customer to simply say "I want this product, here's my budget — who wants my business?"
Customers had no fallback for unlisted products. If a product wasn't in a marketplace's catalog, the buyer was stuck. There was no structured way to surface latent demand to retailers who might actually have the item in stock.
Retailers were burning cash to be visible. Small and medium retailers in Bangladesh were paying for ad placements, fighting for listing positions, and converting at low rates because they had no signal of buyer intent. They were marketing into the dark.
Retailers had no demand intelligence. Existing platforms hide what customers actually want and what they're willing to pay. Retailers couldn't see real-time demand for their categories, couldn't price competitively against known competition, and couldn't move excess inventory strategically.
Negotiation was dead online. The offline haggling culture that's deeply embedded in South Asian commerce had no digital equivalent. Marketplaces had stripped out the bargaining dynamic entirely instead of digitizing it.
Real-time competitive bidding didn't exist for retail. Live-auction excitement was confined to collectibles and B2B. No one had built it as a daily-use retail consumer experience with sub-second bid updates, urgency timers, and dual-side transparency.
No single app served both personas well. Building separate customer and retailer apps fragments the user base, doubles install friction, and splits the engineering effort. But most platforms that tried a unified app did one persona well and treated the other as an afterthought.
The challenge was to build a marketplace that flips the power dynamic — buyers declare intent, sellers compete in real time — while keeping the experience smooth enough that non-technical shoppers and small retailers can both onboard in minutes.
The problem space had two distinct, equally broken sides:
Customers had zero pricing leverage. On every existing marketplace, the seller dictates the price. Buyers either accept it, jump between five different apps comparing listings for hours, or give up. There was no mechanism for a customer to simply say "I want this product, here's my budget — who wants my business?"
Customers had no fallback for unlisted products. If a product wasn't in a marketplace's catalog, the buyer was stuck. There was no structured way to surface latent demand to retailers who might actually have the item in stock.
Retailers were burning cash to be visible. Small and medium retailers in Bangladesh were paying for ad placements, fighting for listing positions, and converting at low rates because they had no signal of buyer intent. They were marketing into the dark.
Retailers had no demand intelligence. Existing platforms hide what customers actually want and what they're willing to pay. Retailers couldn't see real-time demand for their categories, couldn't price competitively against known competition, and couldn't move excess inventory strategically.
Negotiation was dead online. The offline haggling culture that's deeply embedded in South Asian commerce had no digital equivalent. Marketplaces had stripped out the bargaining dynamic entirely instead of digitizing it.
Real-time competitive bidding didn't exist for retail. Live-auction excitement was confined to collectibles and B2B. No one had built it as a daily-use retail consumer experience with sub-second bid updates, urgency timers, and dual-side transparency.
No single app served both personas well. Building separate customer and retailer apps fragments the user base, doubles install friction, and splits the engineering effort. But most platforms that tried a unified app did one persona well and treated the other as an afterthought.
The challenge was to build a marketplace that flips the power dynamic — buyers declare intent, sellers compete in real time — while keeping the experience smooth enough that non-technical shoppers and small retailers can both onboard in minutes.
Our Solution
We built Offerly, a dual-persona reverse-auction marketplace that runs as a single cross-platform app on iOS and Android. The core mechanic: a customer posts what they want and at what price, sets a 6h / 12h / 24h bidding window, and watches retailers compete in real time. The lowest bidder wins the sale.
Architectural decisions and why they were made:
Single cross-platform codebase. We shipped iOS and Android from one codebase to keep parity tight and shipping velocity high — critical when the bidding logic, real-time updates, and notification handling all need to behave identically on both platforms. Native-quality animations and interactions were preserved through careful gesture and transition work.
GraphQL API as the data layer. Bidding screens pull a lot of nested, interrelated data — product, variants, bids, retailer info, countdown state, customer budget, address, delivery estimate — and most screens only need a subset. GraphQL was chosen so each screen fetches exactly what it needs in a single round-trip, which matters on Bangladesh mobile networks where payload size and round-trip count directly impact perceived performance.
WebSocket-powered real-time bidding engine. This is the heart of the product. New bids appear on the customer's screen with sub-second latency, the lowest-bid indicator updates live across every connected retailer, and rejected bids animate out smoothly. This drives the auction "feel" — the engagement loop that makes Offerly different from a static comparison site.
Firebase Cloud Messaging with intelligent foreground/background handling. Notifications are deduplicated (the same bid event never fires twice), context-aware (no toast spam if the user is already on the bid screen), and queued offline (notifications delivered when the app reopens, with auto-navigation to the relevant screen). Push reliability is non-negotiable for a marketplace where missing a bid means losing money.
Call-style notifications for retailers on Android. When a new offer drops in a retailer's subscribed category, the alert behaves like an incoming phone call — full-screen, ringing through the lock screen. Retailers told us during research that they'd miss high-value offers when their phone was idle. This was the fix.
Dual-persona single app. Customer and retailer modes live in the same binary with completely separate experiences — 17 customer screens, 10 retailer screens, and 3 shared payment screens. This avoids fragmenting the user base across two installs and lets us iterate on shared infrastructure (auth, payments, notifications) once.
Two bidding strategies for retailers. A retailer can either submit a Fixed Bid (all-inclusive amount that beats the customer's budget) or Suggest a Similar Product from their inventory with a written justification. The second mode turns the bid screen into a consultative sales surface — niche retailers win on knowledge, not just price.
Update-only-downward bid logic. Retailers can lower their bids but never raise them, can't submit the same amount twice, and can't switch bid type after submission. These constraints prevent gaming, keep the auction monotonically favorable for the buyer, and protect platform trust.
Custom Product Requests with image upload. Customers submit up to 5 reference photos for products not in the catalog (Title up to 150 chars, description up to 500). The request is approved, then routed to retailers as a normal biddable offer. This captures demand that would otherwise leak out of the platform.
Barcode/QR scanning for instant product lookup. Camera-based scanning lets customers point at any product packaging and pull up the listing — friction-free price discovery.
Encrypted local storage + OTP email verification + payment-gateway tokenization. Sensitive data (auth tokens, credentials) is held in device-encrypted storage, sign-up requires a 5-digit OTP, password rules enforce 8+ chars with a number and symbol, payments run through a certified gateway with risk assessment on every transaction, and addresses are encrypted at rest.
Structured refund flow with photo evidence. 9 categorized reasons, 500-char description, up to 5 evidence photos, full timeline tracking, return-shipping receipt upload, 5–7 business day SLA. Trust at scale needs structured dispute resolution, not free-text email tickets.
Live competitive intelligence for retailers. Each retailer sees the current lowest bid in green, their own bid in blue, and total bid count — enough context to bid sharply without revealing individual competitor identities.
Centralized string system. All copy is routed through a single localization layer so we can launch additional languages without touching component code.
Deep links for marketing campaigns to land users directly on specific offers, products, or screens.
Tech stack: Cross-platform mobile (iOS + Android single codebase), GraphQL API, WebSocket layer for real-time bid events, Firebase Cloud Messaging for push, certified payment gateway integration, encrypted device storage, GPS-based address auto-fill and weight-based delivery cost calculation, camera-based barcode/QR scanning.
Architectural decisions and why they were made:
Single cross-platform codebase. We shipped iOS and Android from one codebase to keep parity tight and shipping velocity high — critical when the bidding logic, real-time updates, and notification handling all need to behave identically on both platforms. Native-quality animations and interactions were preserved through careful gesture and transition work.
GraphQL API as the data layer. Bidding screens pull a lot of nested, interrelated data — product, variants, bids, retailer info, countdown state, customer budget, address, delivery estimate — and most screens only need a subset. GraphQL was chosen so each screen fetches exactly what it needs in a single round-trip, which matters on Bangladesh mobile networks where payload size and round-trip count directly impact perceived performance.
WebSocket-powered real-time bidding engine. This is the heart of the product. New bids appear on the customer's screen with sub-second latency, the lowest-bid indicator updates live across every connected retailer, and rejected bids animate out smoothly. This drives the auction "feel" — the engagement loop that makes Offerly different from a static comparison site.
Firebase Cloud Messaging with intelligent foreground/background handling. Notifications are deduplicated (the same bid event never fires twice), context-aware (no toast spam if the user is already on the bid screen), and queued offline (notifications delivered when the app reopens, with auto-navigation to the relevant screen). Push reliability is non-negotiable for a marketplace where missing a bid means losing money.
Call-style notifications for retailers on Android. When a new offer drops in a retailer's subscribed category, the alert behaves like an incoming phone call — full-screen, ringing through the lock screen. Retailers told us during research that they'd miss high-value offers when their phone was idle. This was the fix.
Dual-persona single app. Customer and retailer modes live in the same binary with completely separate experiences — 17 customer screens, 10 retailer screens, and 3 shared payment screens. This avoids fragmenting the user base across two installs and lets us iterate on shared infrastructure (auth, payments, notifications) once.
Two bidding strategies for retailers. A retailer can either submit a Fixed Bid (all-inclusive amount that beats the customer's budget) or Suggest a Similar Product from their inventory with a written justification. The second mode turns the bid screen into a consultative sales surface — niche retailers win on knowledge, not just price.
Update-only-downward bid logic. Retailers can lower their bids but never raise them, can't submit the same amount twice, and can't switch bid type after submission. These constraints prevent gaming, keep the auction monotonically favorable for the buyer, and protect platform trust.
Custom Product Requests with image upload. Customers submit up to 5 reference photos for products not in the catalog (Title up to 150 chars, description up to 500). The request is approved, then routed to retailers as a normal biddable offer. This captures demand that would otherwise leak out of the platform.
Barcode/QR scanning for instant product lookup. Camera-based scanning lets customers point at any product packaging and pull up the listing — friction-free price discovery.
Encrypted local storage + OTP email verification + payment-gateway tokenization. Sensitive data (auth tokens, credentials) is held in device-encrypted storage, sign-up requires a 5-digit OTP, password rules enforce 8+ chars with a number and symbol, payments run through a certified gateway with risk assessment on every transaction, and addresses are encrypted at rest.
Structured refund flow with photo evidence. 9 categorized reasons, 500-char description, up to 5 evidence photos, full timeline tracking, return-shipping receipt upload, 5–7 business day SLA. Trust at scale needs structured dispute resolution, not free-text email tickets.
Live competitive intelligence for retailers. Each retailer sees the current lowest bid in green, their own bid in blue, and total bid count — enough context to bid sharply without revealing individual competitor identities.
Centralized string system. All copy is routed through a single localization layer so we can launch additional languages without touching component code.
Deep links for marketing campaigns to land users directly on specific offers, products, or screens.
Tech stack: Cross-platform mobile (iOS + Android single codebase), GraphQL API, WebSocket layer for real-time bid events, Firebase Cloud Messaging for push, certified payment gateway integration, encrypted device storage, GPS-based address auto-fill and weight-based delivery cost calculation, camera-based barcode/QR scanning.
Results & Impact
*Shipped a fully functional dual-persona marketplace covering 30 distinct screens (17 customer + 10 retailer + 3 shared payment) from a single cross-platform codebase
*Real-time bidding engine delivers sub-second bid updates across both customer and retailer surfaces, replicating a live-auction experience inside a daily-use shopping app
*Retailers can act on new offers in the moment via call-style lock-screen notifications on Android, materially reducing missed-opportunity rate
*Closed the catalog gap with a Custom Product Request flow (up to 5 reference photos) that converts unlisted demand into biddable opportunities
*End-to-end transactional coverage — onboarding, OTP verification, bidding, secure payments, order tracking with delivery timeline, and a structured 9-reason refund system with photo evidence — delivered in a single deployable app
*Real-time bidding engine delivers sub-second bid updates across both customer and retailer surfaces, replicating a live-auction experience inside a daily-use shopping app
*Retailers can act on new offers in the moment via call-style lock-screen notifications on Android, materially reducing missed-opportunity rate
*Closed the catalog gap with a Custom Product Request flow (up to 5 reference photos) that converts unlisted demand into biddable opportunities
*End-to-end transactional coverage — onboarding, OTP verification, bidding, secure payments, order tracking with delivery timeline, and a structured 9-reason refund system with photo evidence — delivered in a single deployable app
