DEV Community: Ibrahim Awab

I built Wait For It: tell an open Gemma what you're waiting for, it checks rarely, and it got 35 of 36 real pages right with 0 false alarms

Ibrahim Awab — Wed, 21 Oct 2026 22:47:05 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 3: Slow and Steady

What I Built

This idea started with me waiting. On Monday I opened my coding agent and typed, word for word: "yo yk how we were waiting for hacktober dev.to week 3 topic. why were we waityinh?" I had been refreshing the challenge page for the new theme, and before that the Week 2 page for results, and before that the petrol price board. I spend a silly amount of my week checking pages for one sentence that isn't there yet.

Wait For It is a web page where you type what you're waiting for in plain words, add a link if you have one, and then stop checking. It looks for you, rarely and on purpose:

You write "the Week 2 winners are announced" with the challenge link, or "پاکستان میں پٹرول کی قیمت بدل جائے" (tell me when the petrol price changes in Pakistan) with no link at all.
Gemma 4, an open-weight model, reads the page (or the past week's Google results) and answers two questions: has it happened, and when should I look next?
When it has happened, or the date moved, you get a browser notification and a short voice note, in English or Urdu.
The rest of the time it stays quiet. A watch for something a month away gets looked at once a week, not every hour.

Who gets to be lazier: anyone waiting on a page that will change once. Students waiting for results, people waiting for a price to drop, developers waiting for a release, and me, waiting for this challenge's own results. The effort it saves is the refreshing and the second-guessing, which for me is many small checks a day.

Demo

The live page is at https://waitforit.onrender.com (free Render instance, so the first load can take up to a minute while it wakes up). Notifications need you to click "Turn on notifications" once.

What a first check looks like. I typed "Linux 7.4 is released" and the kernel.org link, and Gemma's first look came back in about 5 seconds:

The real watches I left running overnight, including two that answer in Urdu. Each card shows what Gemma found, when it will look again, and the expected date it pulled from the page:

Code

miawab / waitforit

Tell it what you're waiting for. Stop checking. Gemma decides when it has happened.

Wait For It

Tell it what you're waiting for. Stop checking.

"Tell me when the results are out" + a link "Tell me when petrol prices change in Pakistan" (no link needed)

It looks rarely, on purpose. Each time it wakes up, Gemma (an open-weight model) reads the page or the latest search results and decides one thing: has it happened, or changed, since I last told you? Then it picks when to look next: once a week if the date is far away, every few hours when it's close. You only hear from it when there's real news.

How it works

A watch = what you're waiting for, plus a link (or nothing, and it searches instead).
A free pinger (like cron-job.org) calls /api/tick every 30 minutes; the server runs only the watches that are due.
Each check: fetch the page (skip Gemma entirely if the page hasn't…

View on GitHub

Plain Node (no framework), about 900 lines. MIT licensed.

How I Built It

The architecture is deliberately boring, because the interesting part is the decision in the middle:

A free pinger (cron-job.org) calls /api/tick every 30 minutes with a secret key. That wakes the free Render server, which runs only the watches whose next check is due, and goes back to sleep. Nothing has to stay on, including my PC.
For a watch with a link, the server fetches the page, strips menus, footers and hidden HTML, and hashes the text. If the hash matches last time, nothing could have changed, so Gemma isn't asked at all.
For a watch without a link, it asks SerpApi for the past week's Google results instead. Gemma turns the person's sentence into a short query once, when the watch is created, because searching the literal Urdu sentence found nothing.
Gemma 4 (26B A4B, the open-weight mixture-of-experts model, hosted on Google AI Studio) gets the request, today's date, what it told the person last time, and the page. It replies with JSON: a status (happened, changed, delayed or nothing), a short summary in the person's language, the earliest and latest likely dates, how many hours until it should look again, and a quote.
MongoDB Atlas holds the watches, their last 50 checks, the browser push subscriptions, the voice notes and the daily counters.
ElevenLabs turns the summary into a voice note (Flash v2.5 handles Urdu) only when something happened or was delayed, never for "nothing".

The model never gets the last word

The first version trusted Gemma's status. That is exactly what keyword alerts get wrong in the other direction: they trust the page. So now Gemma has to show its work. For any news it must copy a few words from the page, and code checks that those words are really there before anyone is told:

// A quote that skips words ("India were champions... beat New Zealand") counts if every piece is there.
export function quoted(quote, text) {
  const norm = (s) => String(s).toLowerCase().normalize('NFKC').replace(/\p{M}/gu, '').replace(/[^\p{L}\p{N}]+/gu, ' ').trim();
  const t = norm(text);
  const pieces = String(quote).split(/\.{3}|…/).map(norm).filter(Boolean);
  // Long enough to mean something: two words, or a number like a version ("158.0").
  const enough = (q) => q.includes(' ') && (q.length >= 6 || (q.length >= 4 && /\d/.test(q)));
  if (!pieces.length || !pieces.every(enough)) return false;
  return pieces.every((q) => ` ${t} `.includes(` ${q} `) || (q.length >= 12 && t.replace(/ /g, '').includes(q.replace(/ /g, ''))));
}

If the quote isn't on the page, the status is downgraded to "nothing", the check is saved with the rejected quote for me to look at, and no notification or voice note goes out. The same idea runs through the rest of the code:

Gemma picks when to look next, but code clamps it to between 30 minutes and 7 days, and forces a look at least every 6 hours once the earliest likely date is within 3 days. In the eval Gemma once asked to sleep for 720 hours (the 2027 Cricket World Cup); the code cut that to a week.
Gemma can say a watch is done, but for anything that happens again ("tell me when the price changes"), code ignores that and keeps watching. I added this after the petrol watch found a two-day-old price cut on its first look and switched itself off.
File links Gemma wants to save have to be copied from the page's real link list; anything it invents is dropped.
The page fetcher refuses private and local addresses, so nobody can point it at the server's own network.

What one check costs

Every key has a hard daily cap stored in the database (so a restart doesn't reset it), because I am a student on free tiers and a loop or a crawler shouldn't be able to spend anything:

Per check	Typical	Daily cap in code	Free tier it protects
Gemma call, page watch	10,383 tokens in, 122 out, about 4 s	400 calls	AI Studio free tier
Gemma call, search watch	about 930 tokens in, 80 out	(same 400)	AI Studio free tier
Gemma call when the page is unchanged	0 (skipped by the hash)	n/a	n/a
SerpApi search, no-link watch only	1 search	8 searches	250 searches a month
ElevenLabs voice note, news only	about 60 characters, 3 s of audio	15 notes	10,000 credits a month; the key itself is limited to 5,000 and to text-to-speech only

On top of that: at most 5 watches per person, 60 in total, 10 new watches per IP per day, and every watch ends after 45 days. I'll delete the keys when judging is over.

What I Measured

A watcher is only as good as its "has it happened?" call, so I built a test set before writing this post. I picked 36 real pages on October 21, wrote a question for each, and labelled every answer by reading the page itself, separately from Gemma:

15 release pages (kernel.org, python.org, nodejs.org, go.dev, the Rust blog, Deno's GitHub releases, Firefox release notes), mostly in pairs on the same page: "Linux 7.3 is released" (yes) and "Linux 7.4 is released" (not yet).
21 Wikipedia pages for events: the 2026 World Cup final (happened), the 2030 World Cup (not yet), GTA 6 (scheduled for November 19), the Nobel Peace Prize winner (announced) and its ceremony (December 10, not yet), and so on.
19 have happened and 17 haven't. The "not yet" pages are the hard ones, because they are full of words like released, announced and champion.

Each page is saved once, so every run reads the same text, and node eval/run.mjs runs the real check (the same checkWatch the server uses, including the quote check) next to a keyword rule that fires when a done-sounding word is on the page. That rule is what a "tell me when this page changes" alert effectively does.

36 pages	Correct	False alarms	Missed
Keyword rule	18	15	3
Gemma 4 + quote check	35	0	1

Split by kind of page, the keyword rule is bad everywhere, and Gemma's only miss is on Wikipedia:

Page type	Pages	Gemma correct	Gemma false alarms	Keyword correct	Keyword false alarms
Release pages	15	15	0	7	5
Wikipedia events	21	20	0	11	10

The second thing I wanted to know is whether Gemma is actually lazy in a useful way. This is what it chose for "when should I look next?" on the same pages, before the code clamps it:

What the page said	Pages	Gemma's next look
It has happened	18	6 to 12 hours (and the watch ends)
Not yet, no date known	6	24 hours
Not yet, a date weeks or months away	10	48 hours to 7 days (one asked for 30 days, cut to 7)
Not yet, missed	1	6 hours

That is the behaviour I hoped for: it looks rarely when the date is far and the page gives one, and daily when it has no idea.

What went wrong

All of these are real, and most of them changed the code:

The one miss is Artemis II. The page says it launched on April 1, 2026 and landed April 11. Gemma read "launch date April 1, 2026" as a plan and said it hadn't happened, even though today's date (October 21) was in the prompt. Dates in the past written like schedules are still a weak spot.
My first full run scored 19 of 36, and 16 of those failures were mine: the free tier limits tokens per minute, and long pages (8,000 to 14,000 tokens each) hit it after two calls. The app now waits as long as Google's error says and carries on, which means a run takes about a minute per page.
One label was wrong, and it was my fault. I marked "Firefox 158 is out" as not yet because my search pattern missed it; Gemma said it was out, and 158.0 and 158.0.1 are both on the page. I fixed the label and added Firefox 159 as the "not yet" case.
The quote check was too strict twice: it refused "158.0" (too short) and a quote with "..." joining two sentences from the T20 World Cup page. Both were true. Version numbers and quotes with gaps now count when every piece is on the page.
Before that, Gemma sometimes returned an empty answer. It thinks before it answers, and with my original 900-token limit the thinking used up the whole budget. I raised it to 2,048 and retry empty or cut-off replies.
Wikipedia pages were wasting the 14,000-character budget on menus, language lists and HTML snippets hidden inside attributes. The text extractor now skips nav, footers, comments and quoted attributes, and the Artemis II page went from mostly menu to the mission facts in the first 1,000 characters.
The local version was quietly broken until I tested it for this post. Ollama gives a model a 4,096-token context by default, so on a 10,000-token page local Gemma only ever saw the first 2,051 tokens and mostly answered with nothing. The Ollama call now asks for 12,288 tokens; 20,480 was too big for my 6 GB GPU and pushed half the model onto the CPU.
The petrol watch switched itself off after its first look, because a recent price cut looked like "it happened". Things that repeat now never end.

What it can't do

Pages that only render with JavaScript, or sit behind a login, come back nearly empty. University portals are the obvious example. A headless browser would fix it, at a cost I haven't paid yet.
It reads the first 14,000 characters of a page. If the news is at the bottom of a very long page, it won't see it.
No-link watches depend on Google having the news in the past week, and on 8 searches a day for the whole site.
The free server sleeps, so a check can run up to 30 minutes late. For exam results that's fine; for concert tickets it isn't.
Notifications need the browser to have been allowed once, and iPhones only show web push for sites added to the home screen.
The test set is 36 pages picked by one person on one day. It shows the idea works and where it breaks; it isn't a benchmark.

Why Does Open Innovation Matter?

For this project it matters for three concrete reasons, not as a slogan.

The first is that the pages people wait on are often private. A results page you are logged into, a supplier's price list, a hospital's appointment page: I don't want any of those going to a company's API just to ask "has it changed?". Because Gemma's weights are open, the same code switches to a model running on your own machine with one setting. Set OLLAMA_URL and Wait For It uses gemma4:e4b-it-qat through Ollama instead of AI Studio, and the page never leaves your PC. I checked this on my own 6 GB GTX 1660 Super with six of the eval pages: local Gemma got 5 right and failed one (the long Firefox release-notes page, where it ran out of time before producing an answer). It is slow, 42 to 124 seconds a page against about 4 seconds hosted, but a watcher that looks once a day can afford to be slow.

The second is cost and control over time. A watcher runs for weeks. With a closed API, the price, the rate limits or the model itself can change halfway through a watch, and I would find out when it broke. With open weights I can pin the exact model the eval was run on, and if the hosted free tier goes away, the fallback is a download, not a rewrite.

The third is that I could build on other open work instead of starting from zero. The Gemma calling code is adapted from my earlier open-source project, scamcheck (credited in the README); edge-tts and Remotion, both open source, made the video; and Ollama makes "run it yourself" a single command. Open models are also what let me look inside the failure: when Gemma returned empty answers, the API showed me the thinking tokens, and that is how I found the budget problem.

The Lazy Payoff

I am using it for the things I'm actually waiting for. These are the five watches running on the live site right now, all started on October 22 at about 2:45 AM my time:

Watch	First answer	Next look Gemma chose
The Week 2 winners are announced (the challenge page)	Expected during the week of October 19	6 hours (inside the window)
Petrol price in Pakistan changes (Urdu, no link)	No new change since the last cut	24 hours
Linux 7.4 is released (kernel.org)	7.3 is the latest, 7.4 not yet	24 hours
GTA 6 comes out (Wikipedia)	Still November 19	7 days
Python 3.16 is released (python.org, Urdu)	Not yet, expected around October 2027	7 days

How much refreshing that replaces depends on how anxious you are, so here is the comparison against someone who checks three times a day, using the schedule rules above and assuming the dates on the pages hold:

Watch	Until	Person checking 3 times a day	Wait For It's looks
GTA 6	November 19 (28 days)	84	about 9: weekly, then every 6 hours in the last 3 days
Linux 7.4	early December (about 45 days, no date on the page)	about 135	about 45: daily, since it has no date
Python 3.16	October 2027	over 1,000	about 60: weekly for a year, then every 6 hours
Week 2 winners	this week	3 a day	4 a day, and I don't have to do any of them

And for every one of those looks where the page hasn't changed, Gemma isn't even asked. That is the whole point: the only looks these pages need from now on are Gemma's, and I can close the tabs.

Prize Categories

Best Use of Gemma: Gemma 4 (26B A4B on AI Studio, or E4B locally through Ollama) is the judge of every check: has it happened, what changed, when to look next, and the quote that proves it, in English or Urdu. Measured on 36 hand-labelled pages: 35 right, 0 false alarms.
Best Use of SerpApi: watches without a link ("tell me when the petrol price changes") search the past week of Google results through SerpApi, with a query Gemma writes once from the person's own sentence, capped at 8 searches a day.
Best Use of ElevenLabs: when something happens or is delayed, the summary becomes a short voice note with Flash v2.5, including in Urdu, through a key restricted to text-to-speech with its own credit limit.
Best Use of MongoDB: Atlas stores every watch with its last 50 checks, push subscriptions, voice notes and the daily spending counters that survive restarts, behind an IP list that only allows the Render servers.
Best Use of Render: a free Render web service is the whole backend; a 30-minute ping wakes it to run only the watches that are due, so nothing stays on between checks.

The code, the eval set and the results file are in the repo. I built this with Claude Code as my coding agent, and it helped draft this post; every number in it comes from the eval output in the repo or from the live site.

pricecheck: my friend didn't know what to offer for a used monitor, so now he gets three numbers

Ibrahim Awab — Wed, 14 Oct 2026 19:04:39 +0000

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

What I Built

A friend of mine in Islamabad needs a monitor. He told me what he wanted like this:

"I want a 27 inch monitor… has to be obviously a reputable brand, I don't know much about monitors tho… like 27 inch IPS, budget maybe around 35k."

Then he said the part that actually turned into a project:

"Don't know how to bargain too. If I had some frame of reference, like someone put a monitor at 55k and I can bring it down to 35k, that would be easy for me. So that's an issue, that I don't know how much I can haggle, plus I don't know much about monitors."

In Pakistan, used electronics mostly change hands on OLX. Every listing is an asking price, and every buyer is expected to bargain. If you don't know what similar monitors usually go for, you either overpay or you insult the seller with a lowball and lose the deal. My friend's problem wasn't "which monitor is best". It was "what number do I say out loud".

So I built pricecheck. You paste an OLX link (or browse a category with filters), and it tells you:

what similar listings usually ask, as a range, not one number
a verdict: good deal, fair, overpriced, suspiciously cheap, or hard to judge
three numbers to use when you bargain: open your offer at, a fair deal is, most you should pay
the similar listings it compared against, what it read from the listing, what to check in person, and what Pakistani shops charge for the same model new

It runs on my own PC with open models. Gemma 4 E4B reads the listings locally through Ollama on a GTX 1660 Super. TabPFN predicts the price range. Plain Python decides the advice.

Who would pay for it: anyone buying used electronics on OLX who doesn't bargain for a living, like my friend. It's also useful to people who resell: the same range tells a seller whether they're asking more than similar listings.

Demo

Live site (browse 500+ priced monitors, no setup): https://pricecheck-gamma.vercel.app

What the recording shows, step by step:

1. My friend's filters. 27", IPS, Islamabad, budget 35,000, plus "include ones I could bargain down to it". One listing matches: an ASUS PB278Q (27", 1440p, IPS) asking Rs 40,000, which pricecheck marks overpriced, 24% above usual.

2. The bargaining panel. Half of similar listings ask between Rs 26,583 and Rs 39,679, so it says: open at Rs 24,500, a fair deal is Rs 26,500 to 32,000, and don't go above Rs 39,500. Below that: what Gemma read from the listing, what to check in person, and the similar listings it compared against.

3. A listing that is not in my data. A Dell SE2717HX (27", IPS, 75 Hz) went up on OLX today for Rs 20,500. I paste the link on the local page and it checks it on the spot: fetches the listing, Gemma reads it, TabPFN prices it against 510 others, code writes the advice.

Verdict: good deal, 29% below usual. Similar listings ask Rs 24,078 to 34,490. Open at Rs 19,000, and don't pay more than the asking price.

4. The Sentry trace of a live check of that same listing (in How I Built It below).

That Dell is exactly what my friend described, inside his budget, with room to spare. It's in Lahore, not Islamabad, which is the kind of thing he still has to decide himself.

Code

miawab / pricecheck

Is this OLX price fair? Gemma reads listings, TabPFN prices them, all on your own PC.

pricecheck

Is this OLX price fair? Paste an OLX link or browse a category, and see what similar listings usually ask, whether this one is a good deal, and what to offer when you bargain.

Everything runs on your own computer with open models:

Gemma (Google's open-weight model, run locally with Ollama) reads each messy listing ("27 inch ips lush condition 10/10 box available") into clean columns.
TabPFN (Prior Labs' tabular model, also local) learns from all the other listings what a similar item usually costs, and gives a price range.
Plain code turns that range into advice: open at, fair deal, most you should pay. The models supply facts; code decides.

Nothing runs in the background. Data only changes when you run the update yourself.

What you need

A Windows, Mac or Linux PC. An NVIDIA GPU with 6 GB+ makes Gemma fast (a few seconds per listing)…

View on GitHub

The live site is static, so anyone can browse the priced listings. To check brand-new links like in the demo, run it locally: the README walks through installing Ollama, pulling Gemma, getting a free TabPFN key, and python -m pricecheck.doctor tells you what's missing.

How I Built It

1. Collect. pricecheck reads OLX's public monitor category: one page every 2 seconds, nothing behind a login. Phone numbers are stripped from titles and descriptions before anything is saved (933 of them had one), and seller names are never stored. On Oct 14 that gave 1,180 listings.

2. Gemma reads each listing, once. OLX listings look like "27 inch ips lush condition 10/10 box available urgent sale". Gemma 4 E4B turns that into columns: brand, model, size, panel, resolution, refresh rate, condition, whether it has a fault, whether the box is included. It runs locally through Ollama, so there's no API bill per listing, and each listing is only read once. 643 listings have been read so far.

3. TabPFN prices each listing from the others. TabPFN is Prior Labs' foundation model for tables: you give it rows with known prices and it predicts prices for new rows, with no training loop on my side. I ask it for the 25th, 50th and 75th percentile, so every listing gets a "usual range", not a single guess. When pricing the whole dataset I use 5 folds, so a listing's own price is never in the rows used to price it.

4. Plain code turns the range into advice. This is the bit I was most careful about. The models supply facts; code decides what to tell a person who is about to spend their money:

def advice(price, q25, q50, q75):
    """Turn a price range into what to do. Code decides; the model only supplied the range."""
    gap = price / q50 - 1
    if q75 / q25 > 2.2:
        verdict, say = "unsure", "Similar listings vary too much in price to judge this one. ..."
    elif price < q25 * 0.6:
        verdict, say = "too_cheap", "Far below similar listings. Check carefully in person: ..."
    elif price <= q25:
        verdict, say = "good_deal", "Cheaper than most similar listings. ..."
    elif price <= q75:
        verdict, say = "fair", "In the usual range. There's some room to bargain."
    else:
        verdict, say = "overpriced", "Above the usual range. Bargain hard or ..."
    target_low, target_high = min(price, q25), min(price, q50)
    return {
        "open_at": round500(min(price, q25) * 0.92),
        "fair_from": round500(target_low),
        "fair_to": round500(target_high),
        "max_pay": round500(min(price, q75)),  # never more than they ask, never above the usual range
        ...
    }

Two rules matter most. It will never tell you to pay more than the seller asked. And if similar listings are spread too wide to judge, it says "hard to judge" instead of inventing confidence.

5. SerpApi checks what shops charge. For listings with a clear model name, pricecheck searches Google Shopping through SerpApi for Pakistani shops selling the same model new (OLX and Facebook results excluded). It only shows one number when the shops roughly agree; otherwise it shows the range and links. Found for 45 listings so far, 19 where shops agree, using 35 searches.

6. Sentry traces every check as an agent run. Each live check is an invoke_agent span, with a chat gemma span for the read and tool spans for fetch_olx_listing, tabpfn_price_range, bargain_advice and serpapi_new_price. Here is the trace of a live check of the Dell from the demo:

The whole check took 19.04 s: OLX fetch 1.06 s, Gemma 5.18 s, TabPFN 10.88 s, the advice itself 6.56 ms, SerpApi 1.84 s. That breakdown is how I know where time actually goes. Without it I would have guessed Gemma was the slow part. It isn't any more; TabPFN is.

7. Any OLX category. Monitors is one "recipe", a small TOML file listing where to collect from and which fields matter. python -m pricecheck.new_recipe phones "<OLX link>" lets Gemma draft a new recipe from real listings, which you then read and fix by hand. Nothing runs on a schedule; prices only update when you run the update yourself.

Results

I wanted to know if TabPFN was actually earning its place, so I compared it with simpler ways to price the same listings. python -m pricecheck.evaluate monitors prices all 510 single-monitor listings, each one without seeing its own price:

Method	Typical error	Within 15% of asking price
Same-specs median (what a person would do by hand)	28.6%	26.3%
Gradient boosting	22.4%	35.3%
TabPFN	19.2%	39.6%

TabPFN's "usual range" contained the real asking price 51% of the time. A 25th-75th percentile range should hold about half of prices, so 51% means the ranges are honest: not too narrow to look confident, not too wide to be useless. On an earlier test with only 27" monitors, TabPFN's typical error was 22% against 35% for the simple rule.

19% typical error sounds large until you remember what it's predicting: asking prices, which are already noisy. Sellers price the same model very differently, and some never expect to get what they ask. The goal isn't to guess the exact number. It's to give someone a frame of reference, which is the phrase my friend used.

Why Does Open Innovation Matter?

For a price checker, the economics decide whether it can exist at all. A check has to cost close to nothing, because nobody pays much to be told what to offer for a 20,000-rupee monitor.

No bill per listing. Gemma read 643 listings on my own 6 GB GPU, and each update only reads the new ones. TabPFN runs on my CPU. The only outside calls are SerpApi for shop prices (35 searches so far, inside the free tier) and Sentry for traces (free tier). Re-reading the whole category costs electricity, not tokens.
I could change how the model behaves. Gemma 4's thinking mode was making each listing take about 20 seconds. Because I run it myself, I turned it off and forced its answer into a fixed JSON schema, which brought it down to 5-7 seconds and gave me the "has a fault" field that fixed the broken-monitor mistake.
Swapping models is one setting. On a weaker PC, PRICECHECK_MODEL=gemma4:e2b-it-qat switches to the smaller Gemma. Nothing else changes.
No listing goes to a model provider. The only things that leave my PC are the shop-price searches and the Sentry traces. The listings are public, but I still strip phone numbers before saving anything.

I didn't benchmark a closed API against this, so I can't claim it would be less accurate. The win is that running it costs me nothing per check and I control every step, which is what makes it something a person could actually sell.

My First User

My friend tried it before I wrote any of this. His reaction:

"W, this is nice. Does this take into account how old a model is? Good though, very helpful."

His question is a good one, and the honest answer is: partly. pricecheck uses how long a listing has been up, its condition, and its specs (refresh rate, resolution, panel type), and those track a model's generation fairly well. But it does not know a model's release year. A Dell P2719H from 2018 and a P2725H from 2024 are both "27-inch 1080p IPS Dell" to it, and they shouldn't be priced the same. That's the first thing I'd add next.

I also asked him straight out whether he would pay for it. His answer:

"lol if i had the money yeah. but yeah def a lot of ppl would"

Fair point: a student hunting for a 35k monitor has little to spare. My guess is that the paying users are people with more at stake per purchase, like resellers checking what to ask for their stock, but I haven't tested that yet.

He hasn't contacted a seller or bought anything yet, so I can't tell you how the bargaining went. If he buys one before the deadline, I'll add what happened.

What I'd charge

My friend's answer shaped this. Buyers like him are students with little to spare, so checking a listing stays free. One check costs me a few seconds of my own GPU and CPU, so a few free checks a day per person costs close to nothing.

The paid plan is for resellers, people who buy and sell used monitors and phones on OLX every week. For them the numbers are bigger. In the demo, the ASUS listing asks Rs 40,000 and pricecheck says a fair deal is Rs 26,500 to 32,000. A reseller who gets that one wrong loses more than a month's subscription. What I'd sell them, for Rs 1,000 a month (about $3.50):

unlimited checks
their own listings compared with the usual range, so they know when they're asking too much to sell, or too little
a message when a new listing in their category goes up well below the usual range

The first two already work. The third is the update I already run, plus a message. I haven't asked a reseller to pay yet, so this is a plan, not a result. The next step is to show it to a few resellers in Islamabad and ask.

What went wrong

Gemma marked working monitors as broken. My first schema had one field mixing "what kind of listing is this" with "is something wrong with it". Splitting it into a listing type and a separate "has a fault" field fixed it.
It was slow at first: about 20 s per listing. Turning off Gemma 4's thinking mode and using short JSON keys brought it to 5-7 s.
Some answers stopped mid-JSON. Those are now retried, and Sentry flags them so I can see how often it happens.
The first prices were nonsense for rare items. A 27" 4K monitor "usually" cost 79k to 398k, because a few Apple displays stretched the range. I fixed it three ways: size is required, wildly-off prices are kept out of training, and the "hard to judge" verdict exists for exactly this case.
Sellers mislabel brands. One Koorui monitor was listed under the brand "1st Player". Gemma now reads the brand from the title and description instead of trusting OLX's brand field.
A cold model is very slow. Sentry's first trace showed one check taking 1.84 minutes because Gemma wasn't loaded on the GPU yet. Warm, the Gemma step is about 5 s.
Shop prices from Google are noisy. One Lenovo model was 34k at one shop and 97k at another. That's why the page only shows a single shop price when shops agree.
My GPU ran hot. Under load it sat at 88-91 °C with the fan reading 0%. I stopped Gemma with 562 listings still unread rather than push it. Those listings are collected but not priced on the site.

What it can't do

OLX only shows asking prices, never sold prices. pricecheck tells you what sellers ask, not what buyers paid. Listings that disappear are kept as the closest thing to a sale price, but that's an estimate.
It doesn't know a model's age (my friend's question above).
It can't see the monitor. Dead pixels, backlight bleed and broken ports only show up in person, so every listing gets a short "check this in person" list instead.
It's monitors only, for now. The recipe system works for other categories, but I've only tested monitors properly.

Prize Categories

TabPFN: TabPFN is the decision core of the agent. It produces the 25th/50th/75th percentile price range for every listing (5-fold so no listing sees its own price), beats a same-specs median and gradient boosting on 510 real listings (19.2% vs 28.6% and 22.4% typical error), and its range holds the real price 51% of the time. Code turns that range into the bargaining advice.
Gemma: Gemma 4 E4B runs locally through Ollama on a 6 GB GPU. It reads every messy OLX listing into structured specs, reads brand-new links live during a check, and drafts recipes for new OLX categories.
Sentry (Agent Tracing): every live check is traced as an invoke_agent span with a chat gemma span and four tool spans; the trace screenshot above is from a live check of the Dell listing in the demo. Tracing is how I found the 1.84-minute cold start and that TabPFN, not Gemma, is now the slow step.
SerpApi: Google Shopping results through SerpApi give the new-from-shop price for the same model, so a buyer can see when a used listing costs nearly as much as a new one.

I Love Fragrances, So I Built a 6-Game Arcade + Concierge About My Obsession

Ibrahim Awab — Sun, 12 Jul 2026 09:12:15 +0000

Hi, my name's Ibrahim, I'm a university student, and I have a problem: I love fragrances way more than my bank account loves me for it.

It started small, the way these things always do. A cheap Middle Eastern attar someone gave me as a gift, the kind that costs less than a coffee but somehow smells like it belongs in a much fancier bottle. Then another. Then I started actually reading about notes, pyramids, accords, sillage, the whole rabbit hole. Fast forward through a lot of saved-up allowance and skipped nights out, and I've now got about 20 bottles on my shelf. Mostly affordable Middle Eastern gems (some of them genuinely punch way above their price), with a small handful of designer pieces I saved up for and treat like trophies.

If you're a fellow fragrance enthusiast, you already know the feeling: you don't just "wear" a scent, you collect them, you study them, you have opinions about whether a note is top, heart, or base and you will absolutely fight someone about it. That obsession is basically the entire reason this project exists.

So when I saw the DEV Weekend Challenge's "Passion" prompt, there was only one thing I could possibly build.

What I built: recommendmeafragrance

recommendmeafragrance is a browser arcade for fragrance nerds: six small daily games built around real perfume data (notes, brands, years, price tiers), plus an AI Concierge you can actually talk to about what you're in the mood for. Every game feeds into a personal "shelf" that tracks which fragrances you've discovered, plus streaks so you have a reason to come back tomorrow.

Here's the tour.

🧪 Scentle: Wordle, but for your nose

A new fragrance is picked every day (the same one for everyone, worldwide, no matter your timezone). You get 6 guesses, and after each one you get Wordle style feedback: was the brand exact or just the same house family, did the real answer come out earlier or later than your guess, is it pricier or cheaper, same gender, same concentration, how many notes do you actually share. You can even copy a little emoji share-grid at the end, because obviously.

There's now an Easy/Hard toggle: Easy leans on a famous, recognizable bottle for the day; Hard pulls from the deep catalog for people who want a real challenge.

🔍 Note Detective: reverse engineer a scent from its notes only

This one's my favorite. You're given nothing but notes, revealed one at a time in rotating order (one top, one heart, one base, cycling through the pyramid), and you have to guess the perfume before your score hits zero. Every note you reveal costs points, but the cost is calculated as a percentage of that specific perfume's total note count, so a fragrance with 6 notes and one with 16 notes both cost the same fair share to fully reveal. As you burn through reveals, letters of the name itself slowly uncover hangman-style, so there's a nice tension between "guess now" and "wait, I need one more hint."

Also has an Easy/Hard mode, same famous-vs-deep-catalog split as Scentle.

🧴 Build-a-Bottle — invent your own scent, find out what it actually is

Pick as many top, heart, and base notes as you want from a searchable list of hundreds of real notes, hit "invent," and the app runs a weighted similarity match (base notes count extra, since they carry a scent's identity the most) against the whole catalog to tell you what you basically just invented, plus two runner-up matches. It also treats closely related notes as the same family (so picking "vanilla" still matches perfumes listed under "Madagascar vanilla," etc.), because with hundreds of real notes in the system, exact-string-only matching would've been brutal.

📈 Higher or Lower

Two perfumes, one question: which came out first, or which one's pricier? Keep guessing right to build a streak, one miss ends the run. Easy mode keeps the gap obvious and leans on famous bottles; Hard mode pulls from the deep catalog and can come down to a single year or price tier.

🎰 Scent Roulette

Set some dials (season, occasion, how much chaos you want), pull the lever, get a fragrance recommendation that actually respects your filters instead of just being random.

💘 Blind Date

Swipe through fragrances blind, no brand or hype attached, just notes and vibe, and decide "buy" or "skip." At the end it tells you your "nose score," how many of your buys were actually the famous, universally-loved ones. Humbling, honestly.

Meet the Concierge

Alongside the games there's a chat-style AI Concierge, built to feel like the app's little mascot come to life: warm, encouraging, genuinely curious about what you like, not just a recommendation-spitting bot. Tell it "something warm and cozy for winter nights" and it'll actually ask a follow-up question before throwing fragrances at you, and when it does recommend something, it comes with a real, buyable card attached, not just a name typed in a chat bubble.

Bringing Google AI into it 🔑

This is where I'm submitting for the Best Use of Google AI category. The Concierge runs on a shared daily budget by default so everyone gets to try it for free, but I added a "bring your own Gemini API key" option: paste in a free key from Google AI Studio, and the Concierge switches over to running entirely on Gemini for you, with zero daily limit. The key never touches our servers, it lives only in your browser's local storage and gets sent along with your own requests, so you're fully in control of it. It felt like the right way to let people who want unlimited access get it, without me needing to foot an unlimited AI bill as a student running this on personal savings.

Real bottles, real links

None of this matters if it's just a trivia game, so every single fragrance in the catalog (over a thousand of them) is linked to a live, working offer through FragranceShop.com. Win a game, discover something in the Concierge, or just click "buy" on a card, and it adds to your personal shelf and takes you straight to a real product you can actually purchase. It's a small, honest way to make an app about a hobby self-sustaining without shoving ads in your face.

Try it

🔗 recommendmeafragrance.com

No pressure to sign up for anything just to poke around, though creating a free account (Google sign-in, ten seconds) saves your streaks and shelf across devices and unlocks the Concierge chat.

Closing thoughts

I've genuinely lost track of how many hours went into this between actual classwork, but every time I opened a new bottle from my (very modest, very Middle-Eastern-attar-heavy) collection for "research," it felt worth it. If you're even a little bit of a fragrance nerd, or you just like small, weird, well-made web games, I'd love for you to come play and tell me what your nose score is.

weekendchallenge #googleai #webdev #showdev

I Built a Playable Life Sim That Reveals Your Real Climate Impact at the End

Ibrahim Awab — Sun, 19 Apr 2026 18:27:53 +0000

This is a submission for Weekend Challenge: Earth Day Edition

Earth Day Edition — Earth Impact

What I Built

Most climate apps show you a number.

Earth Impact makes you live one.

It’s a BitLife-style life simulation where you start at age 18 and move through an ordinary life: choosing a career, buying a car, booking flights, investing money, starting a family, upgrading your home. At first, it feels like a normal decision game. Nothing about it feels like an environmental tool.

That’s intentional.

The environmental cost is hidden during play, then revealed at the end.

When the life finishes, the game translates your choices into their real-world consequences: not just tons of CO2, but heat, displacement, harvest loss, water scarcity, habitat collapse, and indirect deaths tied to the cumulative weight of a lifetime. The ending is designed to feel less like a scoreboard and more like a receipt.

The goal wasn’t to lecture. It was to make the player pause.

Demo

earth-impact-three.vercel.app

Code

miawab / Earth-Impact

How I Built It

I structured the project so the core simulation stays fast and deterministic, while AI is used only where it adds value.

Local-first gameplay

Most of the game runs locally. A reducer drives the state machine, so the player’s life progression is predictable and easy to reason about. The game keeps track of age, health, money, reputation, risk, active memories, current scenario, and environmental totals through a central GameState.

A local rarity engine decides which years should trigger meaningful events. Each year can fall into one of several tiers — common, uncommon, rare, epic, legendary, or skip. Skip years still matter: they apply passive environmental and economic drift locally, without making an API call.

That means the game can simulate a full life while only reaching out to Backboard when it has something meaningful to ask.

Smarter scenario generation

Rather than sending an open-ended prompt every time, the game decides the scenario category before the request goes out. That keeps the AI brief narrow and concrete.

The result is a more grounded system:

fewer repetitive prompts,
more relevant life events,
better pacing across the player’s lifespan,
and less unnecessary API usage.

I also added memory and anti-repeat logic so the game doesn’t keep asking the same kinds of questions. If the player already bought a car, married, had children, or made a major purchase, future scenarios can respond to that history instead of ignoring it.

Prefetching and responsiveness

To keep the game feeling immediate, the next scenario is prefetched in the background as soon as the player makes a choice.

That means the game doesn’t sit and wait after every action. By the time the result is read, the next branch is often already ready.

This makes a bigger difference than it sounds like. It keeps the experience from feeling like “request → loading → request → loading” and makes it feel more like a continuous life unfolding.

Final summary system

The ending is where the game becomes more than a life sim.

I built a reference layer of climate and ecological context so the final summary could translate numbers into human-scale consequences. Instead of saying:

“you emitted X tons of CO2,”
“you used Y litres of water,”
“you cleared Z hectares of forest,”

the final panel turns those into:

heat in a specific region,
thirst for a specific community,
forest loss tied to named ecosystems,
and indirect deaths grounded in statistical reality.

That made the ending much more emotionally readable. The player doesn’t just see impact; they feel scale, place, and consequence.

Backboard integration

Backboard is at the heart of Earth Impact’s generative experience. It’s not just used for origin creation, scenario generation, chapter summaries, and the final reflection—it’s also the backbone for persistent memory throughout gameplay.

Unlike typical generative AI setups that invent facts from scratch, Backboard is always provided with structured state, impact data, and tightly scoped prompts. This keeps the narrative grounded and consistent.

Why Backboard?
Backboard’s real strength is in memory storage and continuity. By leveraging its robust memory capabilities, Earth Impact maintains narrative coherence across sessions and player choices. The AI can reference past events and decisions, ensuring that the story evolves in a way that feels meaningful and connected.

Game logic decides the facts
Backboard remembers and tells the story
This approach lets Backboard do what it does best: shape the tone and phrasing of the narrative, while the core game logic determines what actually happens.

In short: Earth Impact decides what happens. Backboard helps remember—and tell—the story.

What I Learned

This project ended up being less about “building a climate game” and more about translating abstract data into something emotionally legible.

A few things stood out:

numbers alone are easy to ignore,
place matters more than scale,
specific human consequences land harder than generic comparisons,
and pacing matters just as much as writing.

The biggest challenge was finding the balance between being truthful and being readable. I didn’t want the ending to feel like a lecture or a guilt trip. I wanted it to feel like a quiet final reveal.

Prize Categories

Best Use of Backboard

Closing Thought

Earth Impact is about the gap between how a decision feels in the moment and what it costs over a lifetime.

At first, it’s just a game about choices.

At the end, it’s a game about consequences.