You are viewing a preview of this job. Log in or register to view more details about this job.

Mobile App Developer

Project Overview

We are looking for a talented, detail-oriented Mobile App Developer to help finalize an on-the-go reselling utility application called Reseller Bro (www.resellerbro.com). The application allows users to instantly analyze product values, get a "FLIP/SKIP" verdict, and save items to a digital cart in seconds.

The application is approximately 80% complete. The front-end user interface, layout screens, and navigation are already fully built out. We are not asking you to build an app from scratch. We need an expert developer to handle the final 20% of the project: optimizing our database cache to hit strict performance targets, implementing an API-driven valuation formula, handling minor UI adjustments, and adding custom audio/vibration triggers.

This is an hourly contract position with flexible hours, perfect for a talented student or recent graduate looking to showcase elite optimization skills.

Long-Term Vision & Equity Potential

While this initial contract is focused on MVP stabilization, we are actively scouting for a long-term technical partner. The engineer who successfully executes this phase and cracks our speed bottleneck will have the first right of refusal for a permanent position as our Lead Developer. You will spearhead the architecture for the upcoming Reseller Bro Ecosystem, which includes dedicated social media features, full B2B cross-platform inventory management tools, and our upcoming wearable AR glasses workflow ("Bro Lens").

Core Responsibilities

Sub-1-Second Centralized Caching: Implement a high-speed database caching layer. While an initial scan of a brand-new item can take time to run the AI workflow and fetch marketplace data, all repeat scans must bypass the AI image recognition entirely, read a cached unique identifier, and pull database results instantly in under 1 second.

Data Engine & Pricing Matrix: Connect the backend cleanly with the official eBay Browse API. Build an automated mapping matrix that groups raw eBay condition data into our 3-tier system 

New Tier: Maps: "New", "Excellent", "Excellent - Refurbished", "Open box", "New with box", "New with defects", and "New without box".

Good Tier: Maps: "Very Good", "Good", "Used", "Very Good - Refurbished", "Good - Refurbished", "Pre-Owned", and "Certified Pre-Owned".

Poor Tier: Maps heavy-wear options directly ("For parts or not working" or "Fair"). If a specific item category lacks a true "poor" marketplace data option, the engine must automatically fall back to calculate a custom percentage markdown (e.g., 40% less) relative to that item's "Good" tier baseline.

Smart Category Specifications (Vehicle & Electronics Handling): If the AI detects an image of a Vehicle or high-value Electronics, the app must dynamically generate a quick-spec form for the user to confirm/fill in (Vehicles: Make, Model, Year, Mileage; Electronics: Brand, Model, Capacity) to feed directly into the pricing API for precise accuracy.

UI Tweaks & Audio/Haptics: Implement minor visual layout edits to existing screens to align with the calculation model. Integrate device vibration triggers (via Web Vibrations API) and custom short audio cues that trigger instantly based on the item verdict.

Deployment & Final Handoff: Successfully deploy the production build live onto our hosting account and provide a clean, documented, finalized source repository.

Qualifications & Requirements

Deep understanding of backend optimization, API data pipelines, and high-speed database caching models.

Proficiency in mobile development frameworks (React Native), Node.js or Python, and front-end audio/haptic integration.

Strong communication skills and the ability to work cleanly within an existing codebase.

Self-motivated engineer who takes pride in performance metrics and clean execution.

How to Apply

Please reply with the word "LAUNCH" at the top of your application so we know you read the full description. In your response, briefly explain how you would structure the database cache so that a repeat scan completely bypasses the image-recognition API step to hit the sub-1-second mark globally.