# Can This Discount Actually Make Money? Building HustleRadar with Gemma 2 and SerpApi

> Source: <https://dev.to/deep_saha/can-this-discount-actually-make-money-building-hustleradar-with-gemma-2-and-serpapi-55h1>
> Published: 2026-10-19 19:25:24+00:00

HustleRadar is a human-in-the-loop AI decision workspace for people who buy expensive products with their own money.

A discounted product is not automatically a good deal. A reseller still needs to know whether the reference price is meaningful, what other retailers charge for the exact configuration, whether the listing is the correct model, what price could realistically be recovered at resale, and what remains after marketplace fees.

HustleRadar turns that research into one workflow:

The system is not an autonomous purchasing agent. It does not buy products or make irreversible decisions. It helps a person make a better decision by reducing research effort while keeping sources, calculations and uncertainty visible.

The core design principle is:

Use AI to explain verified evidence, not to invent the evidence.

Retail websites often make discounts look more attractive than they really are. A product may show a large reduction from an inflated reference price while the same item is available elsewhere for less.

A reseller can also lose money when:

HustleRadar was built to make those risks visible before someone commits cash to inventory.

The user enters a product name or supported product URL. The server normalizes the query and checks the product identity before collecting prices.

The validation layer distinguishes between different generations, product families, storage and RAM configurations, screen sizes, accessories, refurbished listings and invalid prices.

HustleRadar uses SerpApi through three separate evidence paths:

The paths run concurrently. Each provider response retains its status, warnings and source information. A provider error is not silently converted into an empty result or demo data.

The application calculates the market picture before asking Gemma to explain it.

```
estimated net profit = expected resale price × (1 − marketplace fee) − sourcing price
```

The report can include the lowest comparable source, market median, offer price, marketplace fee, projected net profit, margin percentage, provider coverage, timestamps and warnings.

If there is not enough trustworthy evidence, the system returns an insufficient-data result instead of inventing confidence.

Google Gemma 2 receives structured facts after the evidence and calculations are complete. It explains whether the displayed discount is meaningful and whether there is a viable resale margin after fees.

Gemma is not asked to browse the web or invent retailer names. The user can inspect the underlying evidence and challenge the recommendation before making a final decision.

If Gemma is disabled or unavailable, HustleRadar returns a deterministic evidence-backed rationale.

Live application:

[https://hustleradar.onrender.com](https://hustleradar.onrender.com)

API health endpoint:

[https://hustleradar.onrender.com/api/health](https://hustleradar.onrender.com/api/health)

Source code:

[https://github.com/DeepSaha25/HustleRadar](https://github.com/DeepSaha25/HustleRadar)

```
git clone https://github.com/DeepSaha25/HustleRadar.git hustleradar
cd hustleradar
docker build -t hustleradar .
docker run --rm -e ENABLE_LLM=false -p 8080:8080 hustleradar
```

Open `http://localhost:8080`.

The deterministic mode does not require provider credentials and is suitable for reviewing the application flow offline.

Run the automated tests:

```
make test
```

The test suite contains 24 offline tests covering product matching, provider failures, price validation, live/demo separation, deterministic verdicts, Gemma fallback behavior and NDJSON streaming.

Gemma 2 is used as a bounded deal auditor and resale advisor. The model receives normalized product identity, deterministic verdict, confidence, claimed offer price, market median, lowest comparable listing and fee-adjusted arbitrage results.

Gemma explains the result but does not control the correctness boundary. The arithmetic is calculated first, and the evidence remains visible to the user.

Local Ollama configuration:

```
ENABLE_LLM=true
OLLAMA_BASE_URL=http://127.0.0.1:11434
GEMMA_MODEL_NAME=gemma2:9b
```

Deterministic fallback:

```
ENABLE_LLM=false
```

SerpApi provides the market-grounding layer through:

`google_shopping` for structured offers;`as_sitesearch`; and` tbs: "qdr:y"`.
The adapter validates INR currency, retailer URLs, product identity, availability, price ambiguity, model compatibility and provider response status. Foreign currencies, EMI amounts, MRP, ranges, “from” prices and ambiguous promotional values are excluded before they reach the decision engine.

Render hosts the deployed HustleRadar application. The repository includes a `render.yaml` Blueprint that defines the frontend and Node/Express API services.

The deployment provides:

`apps/web/dist`;` apps/server`;`/api/health`; and
The live application is available at:

The development process focused on separating evidence collection, deterministic calculations and AI explanation. I built the application around explicit provider states, conservative product validation and an offline test suite rather than treating a language model response as the source of truth.

The project includes:

`.nvmrc` with Node.js 20.11.1;`package-lock.json`;` Dockerfile`;` make test` command;`.env.example`;` render.yaml`; and` README.md`.
The human chooses the product, offer price and comparison intent, checks whether the product match is correct and decides whether the evidence is strong enough to continue.

The system assists by collecting market evidence, filtering unreliable listings, calculating the financial outcome, showing source coverage and translating structured results into a readable Gemma explanation.

The workflow is:

```
market evidence
    → product and price validation
    → deterministic calculations
    → Gemma explanation
    → human decision
```

This creates a transparent collaboration between the operator and the AI system instead of replacing human judgment with an opaque recommendation.

This project was built as an individual open-source submission. The challenge gave me a reason to turn a practical idea into a complete, explainable product rather than stopping at a prototype.

The most valuable part of the experience was working through the difficult edge cases: wrong product variants, misleading prices, provider failures and model unavailability. Those cases shaped the final architecture more than the happy path did.

I learned that a useful AI product needs clear boundaries. The model can make verified information easier to understand, but the application must preserve the evidence and give the user enough context to make the final decision.

An AI explanation is only as trustworthy as the evidence behind it. A polished paragraph from a language model does not prove that the product match is correct, prices are comparable, the retailer is legitimate, the listing is available or the resale margin is realistic.

The strongest architecture keeps responsibilities separate:

```
market evidence
    → validation
    → deterministic calculations
    → AI explanation
    → human decision
```

When a provider fails, the application can show incomplete evidence. When Gemma is unavailable, the deterministic rationale still works. When a product has multiple configurations, the user can select the correct one instead of accepting a misleading comparison.

HustleRadar is designed for a simple but expensive problem: buying inventory based on a discount that may not be real.

It does not promise guaranteed profit. It does not pretend that every retailer will have stock. It does not treat a language model as a source of truth.

Instead, it gives the user comparable market prices, validated product identity, fee-adjusted margin calculations, source-linked evidence, visible warnings and a concise AI explanation.

The final decision remains with the person who is spending the money.
