DEV Community: Aman Jain

RivalIQ: Giving Small Online Sellers Their Own AI-Powered Competitor Intelligence

Aman Jain — Mon, 19 Oct 2026 06:56:09 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 2: Side Hustle.

What I Built

Imagine you're a small online seller.

You list a stainless steel water bottle for ₹799. But how do you know whether that price is competitive?

You could manually search shopping platforms, compare dozens of listings, inspect product specifications and calculate price differences. Or you could pay for an expensive analytics platform.

I wanted to explore a third option.

Meet RivalIQ — an open-source, AI-powered competitor intelligence tool built for independent e-commerce sellers.

RivalIQ takes a product name, selling price and optional cost, then helps sellers understand the competitive landscape.

It can:

Discover real shopping listings using SerpApi.
Identify potentially comparable products using attribute matching.
Calculate price differences and benchmarks from eligible listings.
Generate evidence-linked insights using Google's open-weight Gemma model.
Recommend actions focused on the seller's own product.
Save reports to MongoDB Atlas for later review.
Run a guided analysis workflow using the open-source Mastra framework.

The distinction that matters most to me is evidence versus assumptions.

A 500 ml plastic bottle shouldn't automatically be treated as equivalent to a 1 litre stainless steel bottle just because both appear in shopping results.

RivalIQ attempts to separate genuine comparisons from broader market observations. When there isn't enough reliable data, it says so.

Who would pay for it?

My target customers are independent online sellers, small e-commerce businesses and marketplace merchants who need competitive intelligence but cannot justify expensive enterprise tools.

A potential business model would be a subscription offering recurring competitor monitoring, saved reports and pricing alerts.

That's the side hustle opportunity: turning an open-source prototype into an affordable intelligence service for smaller merchants.

It's still a prototype, not a commercial product with paying customers.

Demo

Here's a walkthrough of RivalIQ, including its competitor discovery, AI analysis and guided workflow.

Watch the RivalIQ demo on Loom

The demo uses a sample Milton stainless steel water bottle with a selling price of ₹799 and cost of ₹500.

The analysis demonstrates how RivalIQ turns retrieved listings into a structured report and seller-focused guidance.

The application currently runs locally with Ollama. A public hosted deployment is not required to watch the demonstration.

Code

GitHub: MrCyberlord/RivalIQ

The project is publicly available under the MIT license.

It includes the React frontend, FastAPI backend, Mastra orchestration service, tests, setup instructions and architecture documentation.

How I Built It

I used several technologies, but each has a specific responsibility.

React + TypeScript + Vite powers the user interface where sellers enter product details, inspect competitor evidence and reopen saved reports.

Python + FastAPI handles the core intelligence pipeline: input validation, shopping discovery, attribute matching, pricing calculations, AI integration and persistence.

SerpApi retrieves real Google Shopping listings. RivalIQ preserves source references so sellers can inspect the underlying evidence rather than relying on unexplained AI conclusions.

Gemma 3 4B through Ollama is the AI engine. It helps formulate a broader discovery query and generates structured market insights. The model runs locally, without requiring a hosted LLM API for inference.

Mastra powers an optional guided workflow with four stages: validate seller inputs, generate the report, inspect evidence quality and assemble a seller action brief.

MongoDB Atlas stores completed reports so users can reopen previous analyses without rerunning AI inference or consuming search credits.

Sentry provides backend tracing and performance visibility, with privacy-conscious telemetry.

TabPFN, through the official hosted client, is integrated as an experimental option for predictive pricing. It requires sufficient independent comparable-product observations and explicit consent before cloud processing. I haven't presented it as a working prediction where the necessary data isn't available.

A lesson I learned: AI shouldn't be the final authority

One of the most interesting problems emerged during testing.

An AI-generated recommendation could suggest reducing the price of a competitor's listing rather than advising the seller about their own product.

That sounds small, but it makes the advice practically useless.

So I added a validation layer in FastAPI that checks recommendations for seller direction, source citations, unsupported numerical price targets and exaggerated outcome claims.

Invalid recommendations receive clearly identified deterministic replacements. The system also changes its guidance based on how many comparable offers are available.

The architecture follows a simple principle:

Let AI interpret evidence, but let deterministic code enforce the rules.

The resulting workflow combines the flexibility of a language model with conventional software validation.

Testing and performance

The project passed 256 backend tests and 22 orchestration/frontend tests during the Milestone 5.1 verification, alongside TypeScript checks and production builds.

A previous live guided workflow completed in approximately 83 seconds on local hardware. Local model generation accounts for a substantial part of the processing time.

That is an important limitation and an obvious area for future optimization.

Why Does Open Innovation Matter?

I wanted to build something useful without making access to an expensive proprietary AI service a prerequisite.

Gemma's open weights made it possible to experiment with local inference, inspect how the model behaved and adjust the surrounding validation logic.

Mastra provided an open-source orchestration framework without requiring a hosted Mastra account.

Together with FastAPI, React and the rest of the ecosystem, these tools made it possible to build a complete application that I can study, modify and extend.

Open innovation doesn't eliminate every external dependency. RivalIQ still uses SerpApi for shopping data and optionally integrates hosted services for storage, monitoring and prediction.

But it gives me control over a crucial part of the product: the intelligence pipeline itself.

For a solo developer exploring a side hustle, that flexibility matters.

Prize Categories

I'm submitting RivalIQ for consideration in the applicable open-source AI and partner categories, particularly:

Best Use of Gemma — Local Gemma-powered market analysis.
Mastra — Guided workflow orchestration with validated steps.
MongoDB Atlas — Persistent intelligence reports and history.
Sentry — Backend performance tracing and observability.
TabPFN — Experimental, consent-based predictive pricing integration, with data sufficiency safeguards.

I have not deployed RivalIQ on Render, so I'm not claiming a Render deployment.

What's Next?

RivalIQ is a working prototype, but there is plenty of room to grow.

I'd like to explore scheduled competitor monitoring, improved product matching, faster inference and better pricing intelligence as more real observations become available.

The long-term goal is simple:

Make useful competitor intelligence accessible to sellers who don't have enterprise-sized budgets.

This Hacktoberfest challenge gave me an opportunity to turn that idea into something tangible.

Thanks for reading! I'd love to hear what you'd improve or which feature would be most useful to a small online seller.

Runningo: Less Scrolling, More Running - Powered by Gemma

Aman Jain — Mon, 12 Oct 2026 06:56:34 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

What I Built

Sometimes the barrier to getting outside is a small decision: where should I go with the time I have?

I built Runningo, a mobile-friendly walking and jogging route planner. Choose your starting point, available time and preferred stops, then get a real pedestrian route back.

You can also describe your outing:

“A 30-minute jog with greenery and a 5-minute stop.”

Gemma interprets the request. Runningo reserves five minutes for the pause and plans around the remaining moving time.

The map highlights parks, gardens, scenic viewpoints, fruit shops and drinking-water points where OpenStreetMap has relevant data. Suggested routed stops are distinguished from nearby markers, with warnings when preferences cannot be met.

The goal: less time deciding, more time outside.

Demo

Watch the Runningo demo on Loom

This is a local demo using Gemma through Ollama. There is no public deployment yet.

I manually tested time changes, walking versus jogging and pause-time budgeting in the browser. Jogging produced a longer route for the same time; adding a pause reduced the route distance.

One verified local request returned a 3.221 km pedestrian round trip, with 24.15 moving minutes + 5 pause minutes = 29.15 minutes total.

I have not field-tested the route outdoors.

Code

Runningo source code and setup instructions

How I Built It

Runningo uses React, TypeScript and Leaflet for the interface, FastAPI and Pydantic for the backend and Gemma 3 4B through Ollama for local natural-language interpretation.

The responsibilities are deliberately separated:

Gemma extracts activity, available time, place preferences and pause time.
Pydantic validates the structured response.
FOSSGIS OSRM foot supplies real pedestrian geometry.
Overpass retrieves OpenStreetMap places.
Code calculates time from routed distance and the selected pace.

Gemma never invents route geometry or calculates distance.

A smaller model was not automatically the better choice

I compared three Gemma sizes using the same seven fixed requests, prompt and expected results:

Model	Correct interpretations
Gemma 3 270M	1/7
Gemma 3 1B	3/7
Gemma 3 4B	7/7

The cases included negated preferences, preserving defaults and stop-time allocation. These are results from a small development evaluation, not a claim of general accuracy.

The smaller models sometimes returned structurally valid JSON with incorrect preferences. That taught me to test meaning as well as format. Gemma 4B handled all seven cases correctly, with a warm mean response time of approximately 5.75 seconds on my computer.

Malformed or unavailable model responses trigger an explicitly labelled form fallback.

Handling imperfect external services

Place lookup can time out. I added bounded requests, an alternative endpoint and caching, with separate messages for unavailable data and successful empty results.

Testing also exposed a bug: a failed place lookup could drop the requested pause from the time budget. I fixed it so pause time remains included even without an assigned mapped stop.

The backend has 57 passing tests. TypeScript checking and the production build also pass.

I used Codex to help build and debug the project, then tested the main browser experience myself.

Why Does Open Innovation Matter?

Gemma’s open weights let me run inference locally, compare model sizes and inspect failures without a hosted inference subscription or per-request API charges.

Natural-language interpretation stays on my computer. The mapping portion still needs internet access and sends coordinates to routing and place providers, so Runningo is not an entirely offline app.

OpenStreetMap provides inspectable place data. Rather than treating an AI-generated location as fact, Runningo uses mapped sources and reports missing information.

Together, these pieces let me build a reproducible local AI application with clear boundaries between model interpretation, geographic data and calculations.

Limitations and Next Steps

The current planner tries at most three route candidates and includes at most one preferred mapped place. Routes may retrace paths or undershoot the time budget.

Walking and jogging estimates use fixed speeds. Mapped centres are not verified entrances, and nearby markers do not imply visits. Opening hours, access, road suitability, fruit availability and drinking-water quality remain unverified.

Next, I want to improve route selection, verify park entrances and deploy a public version. Longer term, I’d like people to invite friends for scheduled walks and runs.

Prize Categories

Best Use of Gemma

Gemma 3 4B powers natural-language preference extraction, with documented comparisons against smaller Gemma models.

Attribution

Papa Explain

Aman Jain — Mon, 05 Oct 2026 07:03:28 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

PapaExplain: Making AI Actually Personal

We talk a lot about personal AI assistants.

But I kept thinking: what actually makes them personal?

Maybe the future isn't just one giant AI assistant trying to do everything for everyone. Maybe it's also small AI tools built around the everyday problems of individual people.

So for this challenge, I decided to build one for my father.

What I Built

My father, like many people who aren't deeply technical, sometimes comes across messages where the actual information is simple, but the language isn't.

Banking notices. Bills. Account updates. Service notifications. Formal English with a paragraph of information when what you really want to know is:

“What does this mean, and what am I supposed to do?”

That's the problem behind PapaExplain 🧠.

Paste a confusing message, choose Simple English, Hindi or Hinglish and PapaExplain gives you two things:

a simpler explanation of what the message means
a clear “What should I do?” section

That's it.

I deliberately didn't build another general-purpose chatbot. PapaExplain has one job and I wanted it to do that job simply.

Demo

PapaExplain runs locally on my laptop, so instead of deploying the actual AI pipeline to a cloud service, I recorded the real application running with local inference.

Video demo:

GitHub:

https://github.com/MrCyberlord/ExplainBot

The localhost URL in the demo is intentional. The message is processed by an AI model running on my machine rather than being sent to a hosted LLM API.

How I Built It

The stack is deliberately small:

Python
Streamlit for the interface
Ollama for local inference
Gemma 3 270M as the open-weight model

The architecture is basically:

Message
   ↓
Streamlit
   ↓
Ollama (local)
   ↓
Gemma 3 270M
   ↓
Simple explanation + required action

The prompt asks the model to do more than translate. It should simplify the message while preserving important information such as amounts, dates, deadlines and warnings, then separately explain what action the person needs to take.

Why such a tiny model?

This became one of my favourite parts of the project.

I could have reached for a much larger model, but PapaExplain has a narrow job.

That made me curious:

How small can a useful private AI assistant be?

Gemma 3 270M is tiny compared with the models we normally associate with AI assistants.

That's exactly why I wanted to try it.

Instead of using the biggest model available, I kept both the problem and the prompt constrained. For a lightweight tool designed to understand relatively short everyday messages, I wanted to see how far a small local model could go.

Why Does Open Innovation Matter?

Privacy wasn't something I wanted to add later. It influenced the architecture from the beginning.

Think about the messages someone might want PapaExplain to explain: a bank notice, a bill, an account message or some other personal communication.

Those are exactly the kinds of things I don't want the application to require sending to a third-party AI service.

With Ollama + Gemma, the model inference happens locally.

	PapaExplain	Hosted AI API
Inference	Local machine	Remote server
LLM API key	Not required	Usually required
Per-request LLM cost	None	May have usage cost
Model choice	Can swap local models	Provider dependent
Internet for inference	Not required after setup	Required
Message sent to hosted LLM	No	Yes

A closed API could certainly give me access to a much more powerful model.

But raw model capability wasn't my only requirement.

Privacy, local control and simplicity mattered too.

And that's where using an open-weight model made the project possible in the way I wanted to build it.

What I Learned

The most interesting lesson was that small models become much more useful when the problem becomes more specific.

Gemma 3 270M obviously isn't going to compete with a frontier model on general reasoning, and it can still misunderstand complicated text or occasionally generate something that wasn't present in the original message.

That matters.

For something like PapaExplain, a future version should have stronger safeguards around hallucinations, especially for dates, amounts, URLs and required actions. High-stakes financial, legal or medical messages shouldn't be blindly trusted to a small language model.

Building the prototype made something clear to me:

Getting an AI model to answer is easy. Knowing when its answer should be trusted is the more interesting engineering problem.

How I'd Improve It

PapaExplain is intentionally small, but building it made the next steps pretty clear.
The first thing I'd improve is reliability. A small model can occasionally introduce a detail that wasn't present in the original message, so I'd add structured extraction and validation for things like dates, amounts, deadlines, URLs and required actions before showing them to the user.
After that, I'd explore:

Image input, so my father could simply upload a screenshot instead of copying the text.
Confidence and uncertainty indicators, so the app can say “I'm not sure” instead of confidently guessing.
Model comparison, to test whether slightly larger local Gemma models provide enough improvement to justify the additional resources.
An even simpler one-click interface designed for someone who doesn't care which model, framework or prompt is running underneath. And eventually, I'd love for the interaction to become as simple as: Take a screenshot → give it to PapaExplain → understand what it means.

But I also don't want to lose the reason I built it in the first place.
It should remain a small tool that makes one everyday problem easier.

Code

The complete source code and setup instructions are available here:

GitHub: https://github.com/MrCyberlord/ExplainBot

I also documented the local setup so the project can be run with Ollama and Gemma rather than requiring access to my machine or an external AI API.

My Agent Session

There's one more fun part to how PapaExplain was built.

I used OpenAI Codex as my coding agent during the build.

It helped me turn the idea into the Streamlit application, structure the project, test it, integrate the local model and create the documentation.

So there is something slightly recursive about this project:

I used AI to help me build a personal AI for my father. 😄

Prize Categories

Best Use of Gemma

PapaExplain uses Gemma 3 270M for its core functionality, running locally through Ollama.

I didn't choose the smallest Gemma model simply to say that the project uses Gemma.

It became part of the experiment itself:

Can a tiny Gemma model be useful enough to solve one focused, everyday problem completely locally?

PapaExplain is my attempt to find out.

I started this challenge thinking about something useful I could build quickly for one person.

I ended it thinking a little differently about the phrase “personal AI.”

Maybe personal AI doesn't always need to mean one enormously capable assistant that knows everything about us.

Sometimes it can simply mean building the right little tool for the right person.

One person. One recurring problem. One button.