DEV Community: Ashwin Temkar

I got tired of scrolling for dinner, so Gemma only gets to point

Ashwin Temkar — Mon, 26 Oct 2026 06:59:20 +0000

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

The app is here: foodpivot.ashwintemkar.com

Kiranraj Chintada (@kiranrajchintada302) was on this with me.

What I Built

I got tired of scrolling for dinner, so the app only has to answer one question. What should I eat next?

Not which restaurant is trending. Not who has the better rating. The food.

You tell it where you are. Big cities first: Pune, Hyderabad, Mumbai, Bengaluru, Delhi. It looks at places nearby whose menus are already known, from the map and from what those kitchens publish. Then it looks at you. How you eat. What today or tomorrow looks like. A tag if you have one: healthy, Chinese, light, something you can finish before a gym session. And what you already ate.

Gemma names the dish. The nearby places show up only because they already serve that dish.

You can type things like this.

Gym tomorrow, keep it light.
Chinese, not too heavy. I'm in Kothrud.
Rainy evening in Jubilee Hills. I had biryani yesterday.
Something healthy before a long meeting.
Office lunch, vegetarian, Baner.

The answer is a plate. Hakka noodles. A grilled bowl. Misal. Dosa. Whatever sits closest to the day you just described. The kitchen is where you go to get it, not the thing you had to choose.

Demo

foodpivot.ashwintemkar.com

1. Where you are, and what you feel like.

2. The food. One dish, one reason, from your tags and your last meals.

3. Places nearby that already have it on the menu.

Code

ashwintemkar / foodpivot

Food Pivot

You are tired and do not want to decide dinner. Food Pivot reads the mood, keeps the diet and allergy rules, and asks Gemma 4 to pick one plate that is already on the menu.

The menu, the distance, and the allergies are code. Gemma only chooses among dishes those rules already allowed. Backboard sends that request. If BACKBOARD_API_KEY is missing, the same ranker decides.

Local

docker compose up -d
copy .env.example .env
pnpm install
pnpm db:push
pnpm dev

DATABASE_URL for the local Tiger (Timescale) container:

postgresql://foodpilot:foodpilot@127.0.0.1:55432/foodpilot

Set BACKBOARD_API_KEY. The model defaults to gemma-4-26b-a4b-it through Backboard's google provider. Change BACKBOARD_LLM_PROVIDER and BACKBOARD_MODEL_NAME if your Backboard account lists Gemma under a different pair.

Deploy

Tiger Data. Create a Tiger service, copy the Postgres connection string into DATABASE_URL, then pnpm db:push. The local compose file is the same Postgres shape.

Render. New Blueprint from this repo. It…

View on GitHub

https://github.com/ashwintemkar/foodpivot

How I Built It

The city comes first. The address you give, or the area you pick, decides which known menus we even look at. A rainy night in Pune should not be answered with a kitchen in Hyderabad.

Those menus are the foods we already know are served nearby. Maps tell us the place is close. The published menu tells us the dish is real. We are not asking the model to invent a restaurant.

Your side of it is small. Diet. Allergies. Tags. What the day is for. The last few things you ate. That history stays with the app, in Tiger Data, so "not again" and "something like last time" are about your meals, not about a rating chart.

Gemma 4, gemma-4-26b-a4b-it, reads that and names the food. The call goes through Backboard, one key, so the app is not tied to a single model vendor. Gemma only sees foods that already fit the diet and the area. It returns one dish and one sentence. If the name is not on that list, we keep the closest match from your own preferences.

The app itself sits on DigitalOcean, at foodpivot.ashwintemkar.com, so it is awake when you are hungry. Gemma is not running on a GPU we manage. DigitalOcean serves the page. Backboard serves the model. Tiger keeps what you have eaten.

flowchart LR
    A[Where you are] --> B[Nearby places with a known menu]
    C[Diet, tags, the day, past meals] --> D[Gemma through Backboard]
    B --> D
    D --> E[The dish]
    E --> F[Places nearby that already serve it]

Why Does Open Innovation Matter?

The hard part was never writing a prettier menu. It was refusing to let a model invent dinner.

Gemma is open-weight, so the model behind the suggestion can change without changing the question. Backboard is the door in front of it: one key, and the food decision is not glued to one company's login. What you ate last is ours to keep, in a database we can read, not a memory we have to trust a closed chat to recall. The nearby food comes from places and menus that are already public.

A closed assistant will happily name a famous restaurant. This one names the food, then shows you who nearby already cooks it.

The Lazy Payoff

You stop doing the app's job. You say the day. You get the dish. The places come after, and only the ones that already have it.

Prize Categories

Best Use of Gemma. Gemma 4 names what to eat.
Best Use of Backboard. That call goes through a Backboard key.
Best Use of DigitalOcean. The app is on App Platform at foodpivot.ashwintemkar.com.
Best Use of Tiger Data. What you have eaten stays there, and the next suggestion starts from it.

Dobara: the repair counter where Gemma reads the fault and the graph sets the rupees

Ashwin Temkar — Mon, 19 Oct 2026 06:59:30 +0000

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

What I Built

A phone comes back to the counter and the customer says it is the same problem. The person at the desk has to decide, while the customer is still standing there, whether the repair is free, whether only the labor is charged, or whether this customer still owes the last job and should not get a new one.

Dobara is that counter for a small repair shop. The sample shop is Screenwala, Karve Nagar, Pune: one owner, two technicians, and a book of phones, parts, and unpaid jobs. You type what the customer said, including the Hinglish a real counter hears. A local open-weight model reads the fault. A graph decides the money.

The shop’s promise and the supplier’s warranty are different clocks. Screenwala gives a free comeback for 30 days. The display supplier warrants the part for 90 days. The battery supplier warrants it for 60. The model may name the fault. It may not set the rupees.

The person who would pay is the shop owner, or someone running two or three counters under one name. A free screen given to someone who should have paid, or a paid job given to someone inside the promise, costs the part. On this book that is Rs 1,800 to Rs 4,500. A small monthly fee is cheaper than one wrong comeback. Nobody has paid it yet. That price is a hypothesis.

Three walk-ins are the product.

Rahul Deshmukh says the touch is back. His iPhone 13 had a paid display job, J-104, closed 12 days ago. Imran Shaikh did it. The panel came from Shree Displays. Twelve days is inside thirty. The slip says free comeback, Rs 0, and sends it back to Imran.

Neha Kulkarni says the battery died again. Her Redmi Note 12 was repaired 40 days ago, job J-088, by Sagar Patil. The shop promise is over. CellHouse’s battery warranty is 60 days, so 20 days remain. The slip charges labor only, Rs 400, and leaves the part on the supplier. Sagar takes it.

Amit Joshi wants a screen on the other phone. Job J-091 is still open: a charging port on his Samsung M14, Rs 1,800, six days old, Imran’s job. The slip refuses the new work. Collect J-091 first.

If Rahul says “battery” instead of “touch,” the old display job does not count. That is a new paid battery job, Rs 1,800, assigned to Sagar. The customer’s “same problem” is not evidence. The fault has to match a job in the graph.

The phones, IMEIs, and invoices are invented.

Dobara counter before a decision

Demo

Pick a walk-in, then Decide from the graph. The slip shows the outcome, the amount, the technician, and the path: customer, device, earlier job, part and supplier, and the 30-day rule. End this conversation clears the slip. Ask the book, with “What did we decide about Rahul?”, reads the decision back. Closing the page does not delete it.

Replace the two slips below with screenshots from the running app, and put the video or live URL here.

dobara.ashwintemkar.com

Rahul, free comeback, Rs 0

Neha, labor only, Rs 400

Code

DOBARA

docker compose up -d
py -m pip install -r requirements.txt
py server.py

Open http://127.0.0.1:8080. The graph name is screenwala. FalkorDB Browser is on port 3000. py check.py checks the four outcomes: free comeback, labor only, collect first, and a new paid job when the fault does not match.

How I Built It

The open piece that decides is a Cypher CASE in FalkorDB, not the language model.

CASE
  WHEN unpaid IS NOT NULL THEN 'collect_first'
  WHEN last IS NULL THEN 'new_paid'
  WHEN age <= pol.comeback_days THEN 'free_comeback'
  WHEN last.warranty_days IS NOT NULL AND age <= last.warranty_days THEN 'labor_only'
  ELSE 'new_paid'
END

age is today’s day-number minus the day the matching job was closed. Unpaid work wins first. Then a matching paid repair inside the shop promise. Then the same fault still inside the part warranty, which bills labor only. Otherwise it is a new paid job, priced from the skill: touch Rs 4,500, battery Rs 1,800, charging Rs 1,200. The technician is the person who did the earlier repair, or, for a new job, the available person skilled in that fault.

Gemma 3 4B runs locally through Ollama. It returns JSON: phone, customer, fault. The fault is kept only when the complaint says touch, screen, display, battery, or charging. A fault the model invents is dropped. Amounts never come from the model.

The app is Python, FastAPI, and one HTML page. The graph holds the shop, the policy, people, skills, customers, devices, parts, suppliers, jobs, and decisions. A decision points at the customer, the jobs it used, the policy, and the technician. The next session reads those nodes. There is no second database.

Why Does Open Innovation Matter?

A repair book is phone numbers, IMEIs, and what people still owe. Sending that to a closed API on every walk-in means another company sees the book, and a per-call price sits under whatever fee the shop can charge.

Gemma on the shop machine makes the reading cost electricity. FalkorDB on the same machine makes the rule a query the owner can change: comeback days and labor rupees are properties, not a prompt. The slip can show the path from Neha to J-088 to CellHouse. A closed model can be told to be careful with warranties. It cannot be required to stop at an empty path.

Prize Categories

Best Use of Gemma. Gemma 3 4B, through Ollama, reads every complaint on the shop machine. The graph still sets the outcome.

OpenTrips: should I go out this weekend, with a number you can check

Ashwin Temkar — Mon, 12 Oct 2026 06:54:57 +0000

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

CHECK OUR OPEN APP HERE: OpenTrips

Team: HONEYBEE

Ashwin Temkar (@ashwintemkar ) and Kiranraj Chintada (@kiranrajchintada302 ).

What We Built

OpenTrips answers one question before you leave the house. Should I go out this weekend?

You type a place, two dates, and a sentence about yourself. "Beginner, bad knee, budget 3000 rupees, wants hills." You get three things back.

A go, caution, or wait verdict for rain and landslide risk, with the model's measured accuracy on the screen.
A day by day outdoor plan and a packing list from a model we fine tuned for that job.
A map of recorded landslides nearby, the forecast grid, and places to stay, so you can leave with the plan instead of researching it.

The screen is the planning step. The point of the plan is to close the laptop. It is for anyone planning a walk, a day in the hills, or a camp, anywhere a forecast exists. It is not a hotel trip planner. The itinerary is trails, viewpoints, and short walks sized to ability. Stays on the map are context, not the product.


Product	Outdoor go or wait, plus a plan and a packing list
Risk model	TabPFN on real NASA landslide events
Plan model	Qwen3 8B, fine tuned on Tinker
Weather and rain history	Open Meteo, no API key
Maps	OpenStreetMap and Leaflet
Hosting	Render, API and web app
Saved plans	Postgres, reopen by link, cached for no signal

Split	Majority guess	Logistic regression	TabPFN
Time, last 20 percent of each class	0.556	0.799	0.914 accuracy, 0.972 AUC
Geography, India-tagged rows held out	0.390	0.821	0.899 accuracy, 0.956 AUC

The plan model, on 10 requests it never saw in training: base model 0 of 10, fine tuned model 8 of 10.

The 0.390 majority guess always says non-event, because that is the most common training label outside India. Always saying event on the India rows scores 0.610. TabPFN at 0.899 is above both. The India rows in the csv are 775 events and 496 non-events. The plan result is a small sample. A 95 percent Wilson interval on 8 of 10 is about 49 percent to 94 percent.

flowchart TD
    A[Place, dates, one sentence] --> B[OpenStreetMap coordinates]
    B --> C[TabPFN risk]
    B --> D[Qwen3 8B plan]
    C --> E[Go, caution, or wait plus accuracy]
    D --> F[Days, packing, warnings]
    F --> G[Rule checker]
    G --> H[Saved link]
    H --> I[Leave, plan cached for no signal]

Demo

Video: ADDING_SOON_THE_YOUTUBE_URL

Live app: OpenTrips

The API on a free Render instance can take about half a minute to wake up on the first request.

Screenshots

What the demo should show, in order:

1. Type a place, dates, and a constraint sentence.

2. The verdict appears with accuracy 0.899, not a buried footnote.

3. The day list, packing list, and whether the constraint check passed.

4. The map. Recorded landslides, rain grid, stays.

5. Refresh the saved link. The plan is still there.

Code

ashwintemkar / opentrips

Should I go out this weekend? Rain/landslide risk + AI trip planning, anywhere in the world. Built for Hacktoberfest Open-Source AI Challenge Week 1: Touch Grass.

OpenTrips

Should I go out this weekend?

You name a place, pick dates, and describe yourself in one sentence. OpenTrips returns a rain and landslide risk verdict with the model's measured accuracy, plus a day by day outdoor plan and a packing list. The plan is for walks, hills, and camps. It is not a hotel itinerary.

Built for the Hacktoberfest Open Source AI Challenge, Week 1, Touch Grass.

Code	https://github.com/ashwintemkar/opentrips
Risk model	TabPFN on real NASA landslide events
Plan model	Qwen3 8B, fine tuned with Tinker
Weather	Open Meteo, no API key
Maps	OpenStreetMap

What you get

A verdict of go, caution, or wait, and the accuracy number 0.899 on the screen.
Days, distances, a packing list, and a pass or fail check against your budget and ability.
A map of recorded landslides nearby, the forecast grid, and places to stay.
A link you can reopen. A plan you…

View on GitHub

https://github.com/ashwintemkar/opentrips

File	What a judge can check
`landslide_dataset.csv`	3,935 training rows, events and non events, rainfall features
`train_tabpfn.py`	Time split and India held out split, versus majority and logistic regression
`add_india_negatives.py`	Random India non events, so the India test has both classes
`train_plan_model.py`	Tinker fine tune of Qwen3 8B
`compare_plans.py`	Base model versus fine tuned model on held out requests
`plan_examples.jsonl`	The 24 outdoor prompt and JSON pairs
`rule_checker.py`	Budget and distance checks, used live by the API
`main.py`	`POST /risk` and `POST /plan`
`frontend/`	Form, results, map, saved plan page

How I Built It

Two services. Kiran built the Next.js app people touch. I built the data, TabPFN, the Tinker fine tune, and the FastAPI service. Open Meteo and OpenStreetMap sit in the middle. Neither needs a paid key.

flowchart LR
    U[Person] --> WEB[Next.js on Render]
    WEB --> GEO[OpenStreetMap place search]
    WEB --> RISK[POST /risk]
    WEB --> PLAN[POST /plan]
    WEB --> MAP[Map and nearby layers]
    RISK --> METEO[Open Meteo forecast]
    RISK --> TAB[TabPFN on NASA landslide rows]
    PLAN --> QWEN[Qwen3 8B fine tuned on Tinker]
    MAP --> NASA[NASA events near the pin]
    WEB --> DB[Postgres saved plan link]

sequenceDiagram
    participant P as Person
    participant W as Web app
    participant R as Risk API
    participant L as Plan model
    P->>W: Place, dates, constraints
    W->>W: Resolve the place on OpenStreetMap
    W->>R: Latitude, longitude, dates
    R->>R: Rain windows from Open Meteo
    R-->>W: Risk, verdict, accuracy 0.899
    W->>L: The sentence plus that risk
    L-->>W: Days, packing, warnings, checks
    W-->>P: Plan link they can reopen

TabPFN, on recorded events

The training table is the NASA Global Landslide Catalog plus rainfall from the Open Meteo archive. The raw export has 11,033 events in 142 countries. We kept events located within 10 km. 786 India events passed that filter. 775 of those have rainfall and are in the csv. We sampled the rest of the world down for runtime. Each event gets 1 day, 3 day, 7 day, and 14 day rainfall ending on the event date. Non events are random places and dates run through the same rainfall pipeline. The 496 India non events come from add_india_negatives.py, so the India test has both classes. They are not rainy days at known landslide places with no recorded event. A cut on 14 day rain alone scores 0.819 on India, close to the logistic regression.

landslide_dataset.csv has 3,935 rows. It is committed so the result is not a claim judges have to take on faith.

flowchart TD
    A[NASA catalog, 11033 events, 142 countries] --> B[Keep location accuracy within 10 km]
    B --> C[775 India events with rain in the csv]
    B --> D[960 events sampled from the rest of the world]
    C --> E[Open Meteo archive rain]
    D --> E
    E --> F[1, 3, 7, and 14 day rainfall]
    G[Random non events, same rain features] --> H[Plus 496 India non events]
    F --> I[landslide_dataset.csv, 3935 rows]
    H --> I
    I --> J[TabPFN fit at API startup]

flowchart LR
    subgraph timeSplit [Time split]
        T1[Older rows of each class] --> T2[Train]
        T3[Last 20 percent of each class] --> T4[Test]
    end
    subgraph geoSplit [India held out]
        G1[Every country except India] --> G2[Train]
        G3[India events and India non events only] --> G4[Test]
    end
    T2 --> M[TabPFN versus majority versus logistic regression]
    T4 --> M
    G2 --> M
    G4 --> M

flowchart TD
    R[Live forecast rain plus latitude and longitude] --> P[TabPFN probability]
    P --> W{Score}
    W -->|above 0.6| WAIT[wait]
    W -->|above 0.3| CAUTION[caution]
    W -->|otherwise| GO[go]
    WAIT --> UI[Shown with accuracy 0.899]
    CAUTION --> UI
    GO --> UI

At request time the API pulls the live forecast for those same rainfall windows and asks TabPFN for the probability of a landslide style event. Above 0.6 is wait. Above 0.3 is caution. Otherwise go. The number on the card is the geography split, 0.899. The training table is about 44 percent events, far more common than a real weekend, so the 0.6 and 0.3 cuts are not the chance a wet weekend is safe. Precision and recall stay blank, because we did not compute them. We did not make a calibration plot.

The first evaluation runs looked strong and were wrong. One split had no India non events, so the model was mostly saying "event." We fixed the data and published the number from the fixed split. The holdout is the country tag, not a distance buffer. 130 of the 1,271 India test rows are within 10 km of a training event. The median distance is 99 km. The time split is stratified too. The last 20 percent of each class by date, not one global sort that dumped almost all of one class into the test slice.

Tinker, on an open weight model

The plan is not a second call to a general chat model. The base model is Qwen/Qwen3-8B, which is open weight. We fine tuned a LoRA of rank 16 on Tinker.

Training data is 24 hand written prompt and JSON pairs. Places include India, the US, the UK, Switzerland, Nepal, Japan, Peru, New Zealand, Kenya, France, Iceland, and South Africa. Constraints include a bad knee, asthma, an elderly parent, a toddler, fear of heights, and pregnancy. The instruction prefix is the same at training time and at request time.

The first run was a single gradient step. The model still wrote chain of thought and ignored the JSON. A 20 epoch loop fixed that. The model then repeated the answer until the token limit, because it never learned to stop. We keep the first balanced JSON object instead of training again.

A rule checker scores each plan. Valid JSON, at least one day, a packing list, budget at or under the number in the sentence, and distance per day inside a cap inferred from words like beginner or advanced. Held out result:

	Pass rate
Base Qwen3 8B	0 of 10
Fine tuned checkpoint	8 of 10, small sample

The live /plan route runs that checker. checks_passed is the checker result. It is not hardcoded to true.

Checkpoint: tinker://4deeaa51-09a3-5d86-8281-29ad275d2c0c:train:0/sampler_weights/opentrips-plan-v1

What the app does around those two models

The form resolves the place with OpenStreetMap Nominatim, then calls /risk and /plan. The results page shows the verdict, the accuracy, the itinerary, and a Leaflet map. Map layers are nearby NASA landslide points, an Open Meteo weather grid, and stays ranked by distance and by how close they are to a recorded landslide. A plan can be saved and reopened by link. A service worker caches a plan page you already opened, so that page still loads with no signal.

That is the offline behavior. The models do not run on the phone in the forest. The plan is made before you leave, then cached.

Why Does Open Innovation Matter?

A closed chat API can write a pleasant itinerary. It cannot show a measured error rate on landslide records it was never trained on, and you cannot ship the training table next to the code.

Closed default	What open made possible
Ask a hosted chat model if the weekend looks fine	TabPFN on a public CSV of real events
Labels the author wrote, then a model that copies them	Labels are recorded reports, with a majority baseline and a logistic regression baseline
One country, no held out region	India-tagged rows held out, tested only on those rows, 0.899 accuracy
A base model that chats	Fine tuned open weight Qwen3 8B that emits JSON, 8 of 10 versus 0 of 10, small sample
Weather behind a paid key	Open Meteo, no key
Maps behind a paid vendor	OpenStreetMap
Model swap means a new product	The CSV, the checker, and the API stay. The checkpoint can change

Qwen3 8B weights are public. Tinker let us change them for this task and keep the checkpoint. TabPFN let us treat a few thousand rows as a classifier without standing up a training cluster. The dataset is in the repo so someone else can rerun the comparison.

We do not claim the phone runs the model with no signal. A new plan needs the server, because the forecast and the models run there. The honest offline piece is the saved plan you already opened.

Prize Categories

Best Use of TabPFN. The risk score is TabPFN on historical landslide rows. Baselines are in the table above. Accuracy 0.899 is on every result.
Best Use of Tinker. Qwen3 8B fine tuned to write the plan. Held out pass rate 8 of 10 against 0 of 10 for the base model, a small sample.
Best Use of Render. The FastAPI model service and the Next.js app are both hosted on Render.

Thanks for reading. If the verdict says go, close the tab.

Mentor Me - an AI mentor that reviews code the way I actually would

Ashwin Temkar — Mon, 05 Oct 2026 06:50:03 +0000

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

What I Built

Mentor Me is an AI mentor for a junior developer I informally mentor. She gets code review and "why would you do it this way" answers from me whenever I have a free minute, which is inconsistent and usually late at night. Mentor Me reviews her code on her own schedule and writes up what actually matters so she's never stuck waiting on me, and the feedback still reads like mine, not a generic bot's.

Demo

https://mentor-me.ashwintemkar.com

Code

https://github.com/ashwintemkar/mentor-me

How I Built It

Backboard routes the review request through a single API key to an open-weight model, so the mentor agent isn't locked to one provider.
Tinker (Thinking Machines) fine-tunes a small open model with LoRA on a corpus of my own past review comments, so its feedback carries my actual tone and priorities instead of generic LLM notes. finetune/compare.py samples the base model and the fine-tuned checkpoint on the same prompt, side by side.
Render hosts the app itself (via a render.yaml Blueprint), so my mentee just opens a link nothing runs on my machine for her to depend on.
Sign-in (Google/GitHub) and sessions run on Supabase Auth.

Why Does Open Innovation Matter?

This only works because the model is open-weight. I can fine-tune it on my own private review history no closed, hosted model lets an individual mentor do that without becoming an enterprise customer. Backboard means I'm not locked to one model or vendor, so I can route to whichever open model is cheapest or sharpest that week. And because it costs next to nothing to run, my mentee can ask for a review as often as she wants without anyone metering her, or her mistakes sitting on a server neither of us controls beyond the inference call itself.

Prize Categories

Best Use of Tinker (Thinking Machines)
Best Use of Backboard
Best Use of Render