HustleRadar: Verifying Resale Profits with SerpApi + Gemma 2

A product page showing a list price of ₹22,000 and a current price of ₹15,000 looks like "save ₹7,000." But for a reseller, that number is almost meaningless—the reference price may be inflated for the promotion, other stores may sell it cheaper, platform commissions, shipping, and coupons will eat into the profit, and the cheapest search result might not even be the same product.

HustleRadar was built for exactly this problem: an open-source market evidence and arbitrage decision tool that turns "is this discount real, and how much can I make if I buy it?" into an auditable workflow. According to developer DeepSaha's launch post on Dev.to, it integrates SerpApi's real-time retail data with Google Gemma 2's language explanation capabilities, keeping the two strictly layered—the model only explains, it doesn't invent numbers.

Product Positioning: Not a Shopping Chatbot

HustleRadar deliberately draws a narrow capability boundary. It takes four inputs: product name or link, actual purchase price, optional reference price, and server-side evidence mode (live real-time investigation flow, or explicitly labeled demo fixed data). Then it runs the entire decision loop in a fixed order:

1. Collect evidence from shopping results, specified retailers, and date-bounded context
2. Normalize product identity, excluding accessories, refurbished units, and wrong models
3. Calculate the market picture: lowest observed price, median, source coverage, and post-fee resale margin
4. Present evidence—retailer names, links, prices, timestamps, coverage warnings
5. Call Gemma 2 to translate structured facts into an actionable explanation
6. Fall back to deterministic evidence interpretation when the model is unavailable

Its core promise is a single sentence: Don't buy just because the product page says "discount." See the market, the post-fee exit price, and the evidence behind the recommendation before deciding. The target users are people who spend their own money on high-ticket inventory—electronics flippers, retail arbitrage beginners, freelance studios, photographers, editors, and small e-commerce operators.

Decision Logic: Arithmetic First, Language Second

This is HustleRadar's most important design choice, and what distinguishes it from ordinary AI shopping assistants.

Deterministic Calculation First

Resale margin is computed in TypeScript before Gemma is ever invoked. The current version models the platform fee at 8% and grades opportunities across two dimensions: percentage margin and absolute net profit:

const grossMargin = resaleMedianPrice - buyPrice;
const marginPercent = Math.round((grossMargin / buyPrice) * 100);
const platformFeeEst = Math.round(resaleMedianPrice * 0.08);
const netProfit = grossMargin - platformFeeEst;

if (grossMargin > 0 && netProfit > 0) {
  opportunityScore =
    marginPercent >= 20 && netProfit >= 2000 ? "HIGH" :
    marginPercent >= 10 || netProfit >= 800 ? "MODERATE" : "LOW";
} else {
  opportunityScore = "UNPROFITABLE";
}

The simplified formula is: estimated net profit = expected resale price × (1 − platform fee rate) − purchase price. Shipping, coupons, and bank discounts are modeled separately in the scenario calculator rather than being folded into an optimistic percentage.

Platform fee modeling is the most commonly underestimated or oversimplified part of resale profit calculation. Commission structures across e-commerce platforms are typically a combination of category commission, payment gateway fees, fulfillment fees, and promotion fees, with real deductions often landing between 10%–20%, while the fee logic of secondhand marketplaces is entirely different. HustleRadar currently models the platform fee uniformly at 8%, a simplifying assumption convenient for prototype validation—but its impact is systemic: for every 5 percentage points the rate is too low, net profit is systematically overestimated, and opportunity grades can be misclassified from LOW to MODERATE. Therefore, before using this tool for real purchasing decisions, users should replace this constant with their actual fee rate and additionally account for return losses, inventory turnover time, and capital occupation costs for high-ticket items.

Gemma Gets Facts, Not a Blank Canvas

The prompt sent to Gemma already contains the normalized product name, verdict, confidence, stated price, market median, lowest comparable quote, and the computed arbitrage result. The model is asked to answer only two questions: is the claimed discount real or inflated? And is there viable resale room after deducting platform fees? The prompt explicitly states: "no hallucinating prices or retailers."

The significance of this division of labor: a polished Gemma output is not evidence. HustleRadar's confidence and warnings are based on source coverage and matching results—the model cannot upgrade weak evidence into a strong recommendation through more persuasive phrasing. Setting ENABLE_LLM=false bypasses the model entirely, and the system generates a deterministic explanation from the same structured evidence.

Evidence Collection Is Fully Independent of Conclusions

The backend runs three SerpApi paths concurrently via Promise.all: google_shopping for structured quotes, retailer-scoped search (as_sitesearch) to supplement direct-store coverage, and context search with tbs: "qdr:y" to capture recent price mentions. Each path retains its own status—success, empty, or error. A request that returns HTTP 200 but contains a SerpApi error in the response body is not treated as a "successful but empty" market scan.

SerpApi is a third-party API that converts search engine results pages into structured JSON. It doesn't provide a price database itself; it proxies results from Google Shopping, Google web search, and others. This means the "market evidence" HustleRadar receives is essentially a snapshot of search results with three inherent characteristics: first, coverage depends on keyword and search path design—retailers absent from results don't necessarily not exist; second, results carry timestamps, and prices may become stale within hours; third, time-filter parameters like tbs: "qdr:y" only constrain the freshness of search results, not guaranteeing that the prices mentioned therein are still valid. Understanding these three points is essential to correctly interpreting the source coverage warnings in reports—it measures the breadth of evidence, not the true distribution of the market.

What Actually Takes Engineering Time: Making Failure Paths Honest

The author candidly admits two key bugs in the original post, which is more valuable than showcasing the happy path.

Bug 1: Vendor Failures Silently Looked Like Successful Scans

An early implementation would fall back to demo data when the live vendor failed. The interface looked complete, but the meaning of the word "live" was completely destroyed—resellers would believe the report came from current market evidence. The fix was to write the mode into the evidence contract: live requests stay live, vendor errors stay errors, demo data loads only when mode: "demo" is explicitly requested, partial failures aren't cached as healthy reports, and the interface can display insufficient_data instead of fabricating confidence.

Bug 2: The Cheapest Quote Isn't Always the Right Product

Search engines mix protective cases, replacement parts, previous-generation models, and refurbished units into results. Price aggregation without identity verification is essentially rewarding the wrong listing. The verification layer now checks model identity, condition, accessory keywords, variant attributes, and currency before prices enter the median calculation. If multiple configurations remain, HustleRadar stops and lets the user choose, rather than blending them into a fake median.

The author's example is concrete: when querying "MacBook M5," a cheaper 13-inch or low-storage configuration, if allowed into a comparison with a 15-inch high-storage version, would conjure a seemingly excellent profit margin out of thin air.

Product identity normalization is a core challenge for price aggregation systems. The same product may appear in search engines under different titles, variant attributes, and merchant-custom naming, while accessories (such as cases and power adapters), refurbished units, previous-generation models, and different storage configurations share a lot of keywords. Common approaches include: extracting structured attributes like model and capacity for exact matching, using negative keywords to filter accessory terms, distinguishing new from refurbished by condition tags, and validating currency and region. When multiple configurations remain after matching, the system faces a trade-off—forcing a merge creates a fake median, while discarding outright loses coverage. HustleRadar chooses to have users manually confirm, a conservative approach that returns uncertainty to the decision-maker.

Frontend Experience: Streaming Progress, Not Fake Spinners

Search is much slower than local computation, so the API pushes progress events line by line via NDJSON, and the frontend reads the response body incrementally, showing the actual status of each stage—shopping, retailer, context, and analysis. This isn't a decorative timer—it lets users see the report being assembled rather than waiting for an opaque "AI answer." When the browser disconnects, AbortController aborts the vendor requests.

The full stack includes React 18 + TypeScript + Vite + Tailwind frontend, Node/Express API, SerpApi search grounding, deterministic INR parsing with product guardrails, Gemma 2 (via Ollama or a configurable open-model endpoint), and Render Blueprint deployment. The frontend gets the API address via Render's service reference, and both SERPAPI_KEY and GEMMA_API_KEY are sync: false, keeping credentials out of the repository.

What Open-Weight Models Change

The original post specifically discusses the real impact of open models on this product—the answer isn't simply "the model is free."

Local privacy. A reseller's watchlist reveals what products and niches they're hunting. Through Ollama, structured reports can be sent to a local Gemma, and the language generation step doesn't have to leave the laptop. Real-time market search remains an external dependency when enabled, but the inference step can stay local.

Marginal cost. The target users aren't enterprises with AI budgets—they're individuals checking a few products after work. Running gemma2:9b locally has no per-token billing—this doesn't mean the entire stack is free (SerpApi, hosting, and platform fees still exist), but one recurring expense is removed, making small-scale experimentation feasible.

Swappable models. The app owns its prompt contract and evidence schema, so it can switch between local Ollama, a configured open-model endpoint, or the deterministic explanation path without changing the report interface.

Auditable boundaries. The first three steps of the critical chain search → normalize → calculate → explain are visible and testable in the repository, and the open model only receives constrained inputs and can be disabled. For this product, this is more substantive AI safety than claiming "some prompt makes the model error-free."

The term open-weight model refers to models whose parameters can be publicly downloaded and run locally or on own infrastructure—Gemma 2 falls into this category, contrasting with closed-source models accessible only via API. The key difference isn't the capability ceiling but the deployment boundary: open-weight models allow inference to stay local, avoiding sending query content and structured reports to third parties; they also bill by hardware cost rather than tokens, with marginal cost approaching zero, suitable for low-frequency, small-scale personal use. The trade-off is that users bear the burden of model downloads, hardware resources, and version maintenance, and small local models typically perform worse than large cloud models on complex reasoning—which is exactly why HustleRadar constrains the model to the narrow task of "explaining existing facts."

Honesty Validation: 24 Offline Tests

The repository contains 24 passing offline tests covering query sanitization and INR price parsing, accessory/refurbished/wrong-model rejection, demo mode and cache separation, honest handling of live vendor failures, NDJSON streaming progress and results, deterministic explanation when Gemma is disabled, and rejection of ambiguous short links.

Commendably, the author explicitly states what the tests prove and don't prove: SerpApi calls are mocked or disabled, and Gemma is also off in offline server tests, so the tests validate adapter contracts, verification rules, fallback behavior, and the streaming protocol—not external quotas or remote model endpoints. The /api/health endpoint is positioned as a deployment and configuration check, not proof of "a live call succeeding right now."

The original post also lists what the product explicitly does not promise: no guarantee that resellers can sell at the median, no guarantee that retailers still have stock after the scan, no treating displayed MRP as a historical real price, no silently converting vendor failures into demo results, and no claiming that open-weight AI eliminates all costs.

Opportunities and Limitations of This Kind of Tool

HustleRadar's niche is real: decision quality in retail arbitrage and secondhand resale has long relied on personal experience and manual Excel calculations, while large language models happen to excel at organizing multi-source facts into a human-readable paragraph. Separating arithmetic from language, evidence from conclusions, and live from demo—these three boundaries offer reference value for any product that wants to embed LLMs into money decisions.

The limitations are also clear. The 8% platform fee is a fixed assumption, and fee rates vary widely across markets and categories; the retailer whitelist and INR parsing make the current version highly tied to the Indian market; and 24 offline tests can't prove the stability of the live data pipeline—the author himself invites user feedback at the end of the post on "which fee rate, market, or product variant the current version gets wrong first." The original post doesn't fabricate paying customers or user testimonials, which maintains restraint.

If a tool consistently helps someone avoid one bad inventory purchase, it has paid value. HustleRadar is currently more of a solidly structured open-source prototype than a validated commercial product—but its answer to "where AI should stop" is clearer than many similar projects.

One-line Summary

HustleRadar collects market evidence with SerpApi, computes margins deterministically, and lets only Gemma 2 handle explanations.

Paragraph Summary

HustleRadar is an open-source market evidence and arbitrage decision tool designed to answer the reseller's most pressing question: is the discount on the product page real, and how much can I make after fees if I buy it? It breaks decisions into four steps—collect evidence, normalize product identity, compute margins deterministically, and generate explanations with Gemma 2—where the model only receives structured facts and doesn't participate in price discovery. The engineering focus is on making failure paths honest: live vendor failures aren't silently replaced with demo data, accessories and wrong models don't pollute median calculations, and the system can return insufficient_data rather than fabricating confidence. The 24 offline tests validate adapter contracts and fallback behavior, not external service availability.