
Gamified Pseudo-Auction platform build required
- or -
Post a project like this- Posted:
- Proposals: 24
- Remote
- #4495934
- OPPORTUNITY
- Expired








Description
This is NOT a standard, boring table-comparison site. Instead, it is built as a Pseudo-Live Flash Auction. The consumer inputs their smartphone model and condition, triggering a 15-second live interactive "bidding war" animation between major recyclers (MusicMagpie, Envirofone, Mazuma, etc.). The system calculates the true highest scraped market value on the backend and displays it dynamically as the winning bid. When the user clicks "Accept Bid," they are transferred via a custom dynamic affiliate deep-link to the target reseller to finalize the payout.
The front-end design must be dark-themed, ultra-premium, high-converting, and heavily optimized for mobile taps (resembling a fast-paced fintech app or stock-market ticker).
Core Tech Stack
• Frontend: Next.js (React), Tailwind CSS, Framer Motion (for the real-time cascading bid animations).
• Backend: FastAPI (Python) or Node.js to manage parallel asynchronous web requests.
• Database/Caching: Redis (or simple in-memory cache layer) to store daily fetched phone price metrics.
Core Functional Requirements
1. Multi-Step Conversational Onboarding (Frontend)
• Clean, zero-friction 4-step selector form: Brand ➔ Model ➔ Capacity ➔ Condition (Pristine, Good, Poor, Faulty).
• Auto-suggestions or simple dropdowns for quick access to core models (e.g., iPhone 13 through iPhone 17 Pro Max).
2. The 15-Second Flash Auction Engine (The Core Feature)
• Once submitted, transition to a custom loading page that behaves like a live auction floor.
• Frontend State Machine Animation: Bids must pop up consecutively every 600ms–800ms with a rising value counter.
• The Pacing Logic: The backend will provide the true highest and lowest scraped prices. The frontend will generate 5–6 transitional steps (starting at ~70% value) assigning fake rising counter bids to partner brand logos, concluding exactly at the real maximum scraped price for that device tier.
3. High-Speed Asynchronous Pricing Backend
• Parallel API execution or web crawlers to poll internal XHR endpoints of the top 5 recyclers simultaneously when a model is queried.
• Implement a 24-hour cache layer (Redis or lightweight server-side storage) so that if a device model has already been searched that day, the system serves the values instantly (<150ms) instead of running a fresh scrape.
4. Transition Intermediary Page & Affiliate Deep-Linking
• When "Accept Bid" is selected, trigger a 3-second animated intermediary screen showing confirmation text: “Securing £XXX Offer Token... Transferring to [Partner] Portal.”
• Dynamic formulation of target affiliate links using deep-link paths for Awin/Impact networks.
Deliverables & Milestones
• Milestone 1 (UI/UX Implementation): Interactive multi-step selector setup and complete 15-second Framer Motion animation loop using mock JSON datasets.
• Milestone 2 (Backend Core): Python FastAPI script or Node service mapping the asynchronous lookup framework across the top 4 target platforms, with a simple cache management layer.
• Milestone 3 (Integration & Deployment): End-to-end integration of frontend events with real data feeds, configuring the intermediary transfer screen, and launching on Vercel/Render.
Applicant Requirements
• Strong portfolio showcasing fluid React web animations via Framer Motion or GSAP.
• Clear experience with web scraping using Playwright / Puppeteer / Beautiful Soup or manipulating internal API requests.
• Familiarity with setting up affiliate tracking links or deep-linking architectures is a major plus.
Please provide examples of previous interactive dashboards, gamified web components, or scraper engines you have engineered when applying.
Conor B.
100% (4)New Proposal
Login to your account and send a proposal now to get this project.
Log inClarification Board Ask a Question
-

A few important questions before starting:
1. Do you already have affiliate partnerships/accounts approved with Awin/Impact or should that setup also be handled?
2. Are the recycler sites already finalized or will more platforms be added later?
3. Do you want actual live scraping on every new query, or would partially scheduled/background scraping also work for scaling? -

"For the scraping layer — are the recycler sites (MusicMagpie, Envirofone, Mazuma etc.) exposing internal XHR/API endpoints you've already identified, or do you need me to reverse-engineer those as part of the build? Also, any preference between FastAPI (Python) and Node.js for the backend, or are you leaving that to the developer?"
-

* Are you already aware which recyclers expose stable internal XHR/API endpoints versus requiring full browser automation scraping with Playwright/Puppeteer?
* Do you want the auction pacing and bid progression to feel identical every time for consistency, or dynamically generated based on real price spread, recycler count, and response timing?
* How accurate does the device condition logic need to be initially — simple predefined tiers, or more advanced grading rules per recycler/platform?
* Will affiliate deep-links be supplied directly by your Awin/Impact setup, or should the system dynamically generate tracking parameters and routing logic itself?
* Are you expecting the backend to scrape live on-demand for every uncached request, or would you prefer scheduled background refresh jobs to pre-populate Redis for common models?
* How important is anti-bot resilience and scraper survivability long-term, considering many recycler sites change structures or rate-limit aggressively?
* For the frontend experience, do you want the auction to behave more like a premium fintech/trading interface, or more playful/gamified like a live bidding game?
* Will the platform eventually support other device categories (tablets, watches, consoles, laptops), and should the architecture be designed around that scalability now?
