DEV Community: Kaustubh Jogle

Uncommit the Dead: my unfinished side projects want one last commit

Kaustubh Jogle — Wed, 28 Oct 2026 18:51:06 +0000

This is a submission for the Hacktoberfest Open-Source AI Challenge Week 4: Ghost in the Machine

What I Built

“I’ll finish it this weekend” sounds harmless until you find it attached to an old commit, sitting beneath a feature you still remember explaining enthusiastically to somebody who has probably forgotten the conversation.

I wanted to give that particular kind of unfinished business somewhere to go, because an abandoned repository can still contain a useful idea even when nobody wants to rebuild the entire thing. Including its original developer.

Uncommit the Dead lets you choose a local Git repository and ask an open-weight model for a smaller next step, based on the limited evidence the application collects from its remains. The ghost is your code. And yes, it has pumpkins, because I apparently decided ordinary software maintenance needed seasonal produce.

One last commit

Give the model a time budget and it proposes a small change with a suggested acceptance check, rather than treating your neglected weekend experiment as an invitation to design another startup. Twenty minutes counts.

Donate its organs

But perhaps the whole project should stay buried, while one useful component deserves an extraction plan that identifies what you would need to inspect before carrying it into a different codebase. Keep the good bit.

Rest in peace

Or ask for a farewell document based on the repository evidence, acknowledging the unfinished work without pretending every experiment needs to become a product before you are allowed to leave it behind. A dignified README funeral.

Demo

uncommit-the-dead.vercel.app

The application runs on your machine, where its server can read a selected repository and send the collected context to Ollama without requiring a hosted inference service to handle that evidence. Bring your own ghosts.

After installing the project dependencies, start Ollama and download a model using the command below, then run the development server and open the local address printed in your terminal when it starts. The setup page helps.

ollama pull gemma3:4b
npm run dev

Inside the Graveyard, choose an installed model through the connection panel and use the folder picker to select a repository, or explore a fictional sample before inviting your own unfinished work inside. Samples are labelled clearly. The responses still come from a model request rather than a prerecorded script pretending to think.

Code

Kaustubhjogle / Uncommit-the-Dead

Uncommit the Dead

A little afterlife for the side projects you swore you would finish.

Run locally

Node 20.9+ and Git required.

npm install
npm run dev

Open http://127.0.0.1:3000. The app intentionally binds to loopback and is designed for a trusted personal machine, not public hosting.

Ollama setup guide

Read the Ollama README for installation, model downloads, usage, and troubleshooting. The same guide is available in the app at /ollama, with copyable commands and a downloadable README.

Open AI at its core

Install Ollama, start it, and download an open-weight model:

ollama pull gemma3:4b

Use Connect local AI → Check connection and select an installed model. Model choice is yours; review its model licence. After dependencies and model weights are installed, the app does not need cloud inference. Ollama is fixed to 127.0.0.1:11434; no API key is required.

What works

Three labelled fictional repositories to explore the interface…

View on GitHub

How I Built It

The model receives a bounded collection of repository evidence, including README text and TODO lines alongside filenames and recent commit messages, rather than unrestricted access to whatever happens to be on your disk. It cannot inspect everything.

That context goes to Ollama with a response schema, and the server checks returned evidence references against entries that were actually supplied, discarding unsupported references and rejecting a response if none survive. Matching is deliberately narrow.

The small model had opinions

During testing with Gemma 3 1B through Ollama, one supposedly short ghost introduction became a long monologue, while other responses offered plausible advice that still needed someone to inspect it carefully before doing anything. The ghost needed editing.

I added response-length limits and kept the decorative voice short, while retaining the distinction between a proposed plan and something the application has actually executed or checked against a working implementation. It writes suggestions. You still have to decide whether they make sense for the project sitting in front of you.

Why Does Open Innovation Matter?

An unfinished repository can contain notes that were never intended for anyone outside the project, so using a downloaded local model lets the application send its evidence to Ollama on the same machine. No hosted-model key required.

There are exclusions for obvious secret filenames and symlinks, although those exclusions are not a comprehensive secret scanner, and choosing a cloud model would undermine the local inference arrangement described here. Choose a local model.

Once the application dependencies and model weights are installed, the generation path can work without internet.

And open weights let me try a different installed model without replacing the product, while keeping the prompts and response schema available for inspection when the tiny model offers dubious advice about a CSV exporter. The medium is replaceable.

A closed API could generate repository plans too, whereas the local open-weight approach lets this application keep its working evidence on the user’s computer and leaves the model choice under their control. That fits this project.

The Spirit of It

The feature I care about most is Rest in peace, because learning from an experiment should not oblige you to maintain it forever just to justify having spent a few weekends building it. Some projects can end.

Maybe the useful outcome was discovering a framework you enjoyed, or discovering that you did not actually want to operate a social network for houseplants after the initial excitement wore off. The plants will recover.

So the app gives unfinished work a manageable ending, whether that means making one tiny change or finally writing the goodbye that lets you keep the lesson without keeping the entire project alive indefinitely. No streak to protect. There is already enough guilt in an untouched repository without me adding a leaderboard to it.

An old project does not need to become your next company to have mattered, and I wanted this little Halloween application to make revisiting one feel less like being handed another obligation. Just unfinished business.

Prize Categories

Best Use of Gemma applies to the local Gemma 3 1B generation used in the measured sample above, with support for switching installed Ollama models and Gemma 3 4B documented as a starting option. Open weights, actual ghosts.

Next of Care: from discharge papers to a plan the family can share

Kaustubh Jogle — Sat, 24 Oct 2026 12:19:21 +0000

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

What I Built

The day after a hospital visit, somebody usually ends up hunting through a discharge letter again, looking for the one line that says whether a tablet belongs before breakfast or after dinner. Then they do it again. Next of Care turns selected care documents into an editable plan that can be read at a glance, so the family does not have to repeat that search every day. A small relief.

The person using the app selects PDFs, images, or text files in their browser, then reviews and corrects the proposed medicine schedule before taking a copy away. Nothing is silently prescribed. From that reviewed plan, they can make a PDF summary with a compact dosage table, a formatted Excel tracker, a weekly view, or a WhatsApp message for someone helping at home.

Language matters here. A medicine plan written in English may reach a parent who reads Hindi more comfortably, or an elder who would rather receive a Marathi WhatsApp message than open another spreadsheet. So the same plan can be exported in English, Hindi, or Marathi, including the message that is ready to share with a deliberate tap.

Imagine this message arriving after a relative gets home: “Take one tablet after breakfast. Take the second after dinner.” Simple words help. The medicine name and dose still deserve a check against the original instruction, but a readable message means the recipient can see the day’s plan without asking someone to photograph the prescription yet again.

Demo

next-of-care.vercel.app

Next-Of-Care Demo.mov - Google Drive

drive.google.com

Code

Kaustubhjogle / Next-Of-Care

Next of Care

Next of Care is a browser-based, local-first care handoff tool. People select discharge letters, prescriptions, follow-up schedules, and other care documents on their own device. An open-weight model drafts an editable plan, with original wording available where a match is found. The app can create a PDF summary, an Excel medicine tracker, a weekly schedule, and a WhatsApp-ready message.

Run locally

Requires Node.js 20.19+ or 22.12+.

npm install
npm run dev

Open the address printed by Vite. For a static production build:

npm run build
npm run preview

The dist/ directory can be hosted as static files. There are no application API routes.

Try a fictional sample

Select output/pdf/sample-medicine-instructions.pdf in the app. It has a twice daily medicine at 7:00 AM and 7:00 PM, a medicine on Monday/Wednesday/Friday after breakfast, an as-needed medicine, and a follow-up example. All names and instructions are synthetic test data.

How privacy

…

View on GitHub

How I Built It

The interface is a React and TypeScript app built with Vite, while PDF.js reads text from PDFs and Tesseract.js handles image text in the browser. Files stay on the device. For the AI step, Transformers.js runs the open-weight Qwen3 0.6B ONNX model in a browser worker with WebGPU, turning extracted instructions into a draft that the user can edit. Then it is theirs.

The model is downloaded on first use and cached by the browser, so “local” describes where inference happens rather than promising that a new visitor can start with no internet connection at all. That distinction matters. Once the plan is reviewed, browser-side code produces the PDF, Excel tracker, and share text; the WhatsApp action opens a prepared message only when the user chooses it. Their tap, their choice.

I kept the generated plan editable because a neat-looking medicine schedule can still be wrong, especially when source documents contain unusual wording or text recognition misses a line. The source stays close. The language option also applies across the summary, PDF, tracker, and WhatsApp text, with medicine names and source wording kept visible where possible so a family can compare them. Everyone can check.

Why Does Open Innovation Matter?

Medical paperwork can be intimate, and I wanted this tool's ordinary path to work without sending selected files to an application server for processing. The browser does the work. Because the model and inference stack are open, the project can be inspected, changed, and run without a paid inference API sitting between a family and its documents. That feels right.

Another benefit: a developer can swap the model or redesign the export for a household that needs larger type. And they can share it. Open source does not make extraction perfect, but it lets people see how a suggestion was produced and improve the tool instead of treating a black box as the final word.

The Lazy Payoff

This is the kind of laziness I wanted to reward: after doing the careful review once, a caregiver can leave a tracker on the fridge and send the same readable schedule to the person taking the medicine. The papers can rest. Tomorrow’s routine starts from a plan that is easier to find than a folded discharge letter, while the original instructions remain close enough to check when anything is unclear. One less search.

What I Want to Improve Next

Some devices cannot run the browser model comfortably, so I want to offer an explicitly optional hosted model for people who prefer a smaller first download or lack WebGPU support. The app should explain clearly when documents would leave the device, and the local route should remain available for people who want their processing to stay with them. A real choice.

I also want broader OCR language support, stronger checks for translated dose instructions, and an installable offline package that includes what a household needs before the next hospital visit. None of that replaces review. It would make the handoff gentler for more families, especially when the person reading the plan is far from the person who first brought the papers home.

PayUnfold: the line in your job offer worth reading twice

Kaustubh Jogle — Sun, 18 Oct 2026 19:44:43 +0000

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

What I Built

The offer promises ₹1,20,000 in annual variable pay. A few lines later, it says that payment is subject to company discretion and performance criteria.

That second sentence is the one I want a person to notice before they reply, “I accept.”

I built PayUnfold for people navigating a new job. Give it an offer letter and it points to clauses worth clarifying: conditional pay, notice and buyout, bonds or repayment, probation, and work restrictions. Each finding includes the page, the quoted wording, a plain-English explanation, and a neutral question to ask HR. It does not call a clause illegal or tell you to reject an offer.

After joining, you can optionally add a full-month payslip. PayUnfold reads the figures, lets you correct them, and compares monthly basic pay, HRA, and fixed gross with the offer. It keeps CTC, variable pay, joining bonuses, and one month's fixed pay separate. A ₹3,000 gap becomes a question for payroll, not an accusation: was this proration, leave, a changed structure, or something else?

The side-hustle customer I want to test is an independent career coach who reviews offers for clients. A private, source-linked first pass could save them time and help them deliver a better conversation. The current app is a free prototype.

A paid coach workflow is a hypothesis, not a feature I am claiming to have shipped.

Demo

Code

Kaustubhjogle / pay-unfold

PayUnfold

Know what you are signing, then check what you are paid. PayUnfold reviews an Indian job offer for terms worth asking about before signing. After joining, you can add a payslip, correct extracted pay amounts, and compare monthly fixed pay.

This is a local prototype for Indian salaried workers. It suggests questions; it does not decide whether a clause is legally valid, whether an employer made an error, or what financial decision you should make.

Use the theme toggle in the header to switch between light and dark mode. PayUnfold starts with your system preference and remembers a choice made in the toggle when browser storage is available.

Try the fictional example

Install Node.js.
Open a terminal in this folder and run npm install, then npm run dev.
Open http://localhost:3000.
Click Try a fictional example. This works without any AI setup.

Use your own

…

View on GitHub

How I Built It

PayUnfold is a Next.js app with PDF.js for preparing document pages and Ollama for local inference.
The browser renders the selected pages. The local Next.js server talks to Ollama at 127.0.0.1:11434; there is no account or document database.

I split the job deliberately:

The model reads messy documents. Offer letters and payslips do not share one layout or vocabulary. An image-capable open-weight model extracts pay fields and suggests clauses worth clarifying.
The person checks the source. Extracted amounts stay editable. Findings from selectable-text PDFs are shown only when the quote can be matched to the page text; image-read quotes are marked for manual checking.
Code does the arithmetic. TypeScript compares only reviewed monthly fixed-pay amounts. The model never decides whether an employer underpaid someone.

The offer review covers the first six PDF pages or one image. Pay-field extraction uses the page, so a salary annexure farther back needs manual correction. The app says how much it read instead of pretending it saw the whole contract.

Why Does Open Innovation Matter?

A calculator can subtract ₹45,000 from ₹48,000. It cannot tell which number is monthly basic pay, which is annual CTC, or why a variable-pay clause deserves a question. That interpretation is why an open-weight model sits at the centre of PayUnfold. The arithmetic stays ordinary code because it should be inspectable and predictable.

Running the model on the same computer as the app changes the privacy story. An offer letter and payslip can contain salary, address, and employer details. In the local setup, they pass between the browser, the local Next.js process, and local Ollama—not to a third-party AI API. This promise depends on running both programs locally; hosting the app elsewhere would send the document to that host. There are no per-document API charges, although the model still uses your own hardware and electricity.

Open weights also let a user switch models when one struggles with a scan, a layout, or their laptop. I have not shown that a local model is more accurate than a closed API. The advantage I can demonstrate today is control over where the document goes, which model reads it, and whether an API price change breaks the workflow.

The business test comes next: put PayUnfold in front of a career coach and a job switcher, watch where the questions help or fail, and ask whether either would pay for a polished private review. Until then, the most honest line in this submission is that the product works as a prototype; the side hustle is still being tested.

Prize Categories

Best Use of Gemma

Gemma has a clear role. PayUnfold’s beginner setup recommends Gemma 3 4B as the local image-reading model for offer letters and payslips

I Prefer Alarms Over Reminders, But Hated the Clutter. So I automated it - IOS.

Kaustubh Jogle — Sat, 10 Oct 2026 22:37:06 +0000

I have a habit of setting alarms for almost everything I need to remember.

I know the Reminders app exists, but I've always preferred alarms.

The reason is simple. I find it too easy to ignore a reminder notification. It pops up, I dismiss it, and sometimes I end up forgetting about the task altogether.

An alarm, on the other hand, actually rings. It grabs my attention and makes it harder for me to ignore whatever I was supposed to do.

For me, that's a much better way to remember things or make sure I get something done.

But there's one problem with this habit.

After creating alarms for different tasks, my iPhone's Clock app starts filling up with alarms I no longer need.

And then comes the most annoying part: deleting those alarms, one by one.

Opening the Clock app, finding the old alarms, and manually deleting them gets tiring pretty quickly.

I wanted to keep using alarms without having to deal with the clutter.

That's when I decided to try something with Apple's Shortcuts app.

It's one of those built-in iPhone apps that I feel is seriously underrated. You can automate quite a few things without installing another app or writing code.

So I created four iOS Shortcuts to make managing my alarms easier.

1. Set Alarm Pro: Create an Alarm Without Opening the Clock App Link

The first shortcut is called Set Alarm Pro.

It's pretty straightforward.

When the shortcut is clicked, it asks for two questions:

What time should the alarm be set for?
What is the alarm for?

But before creating it, the shortcut adds the &: prefix to the title. So every alarm created through Set Alarm Pro follows the same naming convention.

The alarm appears in the Clock app like any other alarm. The difference is that my other shortcuts can now identify it.

2. Delete Alarm Pro: The Shortcut I Actually Needed Link

This is the main reason I started building the whole thing.

I was tired of manually deleting alarms that I had already used.

And when you create a lot of alarms for different tasks, that cleanup becomes unnecessarily repetitive.

When the shortcut is clicked, it gives two options:

Option 1: Delete Specific Alarm

Sometimes you want to delete only one alarm while keeping the others.

Instead of scrolling through the entire alarm list, the shortcut:

Finds alarms whose labels contain &:.

This makes it much easier to find and remove an alarm without going through the Clock app.

Option 2: Delete All

This is my favourite part.

Let's say we've created several task-related alarms for a day and no longer need them or want to clear today's alarms.

Normally, we'd have to open the Clock app and delete each one individually.

With Delete Alarm Pro, We can simply select Delete All.

The shortcut uses the Find Alarms action to find alarms containing &: in their labels and deletes them.

And because my regular alarms don't use this identifier, they aren't included in the cleanup.

This was the biggest improvement for me.
A small thing, perhaps, but it solves an annoyance I kept running into.

3. View Alarms Pro: Check All The Task-Related Alarms Link

Sometimes we want to see which task-related alarms we've created without searching through the entire alarm list.

The shortcut gives a quick overview.

If no matching alarms are found, it simply shows:

No alarms found.

Nothing complicated, but it's convenient when we just want to check my alarms.

4. Alarms Pro: Bringing Everything Together Link

After creating the three shortcuts, I thought it would be better to have everything accessible from one place.

That's how the fourth shortcut, Alarms Pro, came about.

It combines the functionality of the other three shortcuts.

From a single shortcut, One can:

Set an alarm
Delete an alarm or clear matching alarms
View existing task-related alarms

Instead of running three separate shortcuts, We can use one entry point for the entire workflow.

Making It More Convenient with a Home Screen Widget

There's another thing I like about this setup.

I don't even have to open the Shortcuts app to use it.

Apple lets you add shortcuts to your iPhone's Home Screen through a Shortcuts widget.

So I can keep the shortcuts accessible directly from my Home Screen.

It's a small convenience, but it makes the whole workflow much more practical for everyday use.

Here's how they work.

The Idea: Give Alarms a Unique Identifier

Before explaining the four shortcuts, there's one small detail that makes everything work.

Whenever I create an alarm using my shortcut, it automatically adds &: to the beginning of the alarm title.

For example, the format looks like this:

&: [Alarm Title]

Why &:?

There's nothing special about these characters themselves. I just needed a consistent way to identify alarms created through my shortcut.

This prefix acts like a tag.

Later, when I want to view or delete those alarms, my other shortcuts search for alarms whose labels contain &:.

That way, I can manage my task-related alarms separately from my regular alarms.

It's a simple naming convention, but it's the most important part of the whole setup.

I used &:, but you can change the prefix if you prefer.

Just make sure it doesn't already appear in the titles of alarms you want to keep, since the filter searches for matching text in the alarm label.

Final Thoughts

I still prefer alarms over reminders.

Maybe it's because an alarm is harder for me to ignore, or maybe I've just become used to relying on them.

Either way, alarms work better for the way I remember things.

What I didn't like was how cluttered my alarm list became and how tedious it was to delete the alarms afterwards.

These four shortcuts let me keep using alarms the way I like, without the manual cleanup every time.

And that's what I enjoy about the Shortcuts app. Sometimes you don't need a complicated solution. A few built-in actions and a simple idea can solve a surprisingly annoying problem.

If you haven't explored Apple Shortcuts yet, I'd definitely recommend giving it a try.

Links:

1. Set Alarm Pro: Link

2. Delete Alarm Pro: Link

3. View Alarms Pro: Link

4. Alarms Pro: Link

I'm curious: do you prefer alarms or reminders for remembering tasks?

Escaping the Mumbai Local: I built an AI app to give commuters outdoor side quests (and literally "touch grass")

Kaustubh Jogle — Fri, 09 Oct 2026 23:02:43 +0000

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

What I Built

In Mumbai, we know our stations. We know which train to catch, where to change, and which platform gets us home. But ask what grows a short walk outside that station, and the answer gets less certain.

That gap became Platform to Park.

It turns a Mumbai railway or metro stop into a small outdoor mission: find a nearby mapped green space, discover what people have observed around it, and leave with one thing to notice. Choose a station. Generate a mission. Pocket the phone.

The idea started with station connections—those awkward gaps between a railway station and a metro stop with a similar name. Then I found a question I liked more: What if the space outside a station was somewhere worth spending a little time?

Platform to Park is for the commuter who has room for a small detour. You don’t need hiking gear, a weekend plan, or a trip out of the city. You can start at a station you already use.

The mission gives that detour a purpose. Look closely at a leaf. Listen for a bird. Notice something you normally pass at commuter speed. There’s also an optional Pocket Mode, which uses ElevenLabs to read the mission aloud. It’s a simple interaction with a specific job: help you stop looking at the app.

My favourite line in the interface is what appears when you take a mission:

Phone down. Eyes up.

That’s the intended outcome.

Demo

platform-to-park.onrender.com

The quickest way to explore it:

Search for a supported Mumbai railway or metro station.
Generate an outdoor mission.
Check the mapped green space and the linked observation sources.
Take the mission with you.

For the Gemma experience, run the project locally with Ollama. The mission card identifies when Gemma generated the text, so it’s clear which mode you’re seeing.

The hosted app also works when local inference isn’t available, using a mission assembled from the retrieved open data.

Code

Kaustubhjogle / platform-to-park

Platform to Park

Turn a Mumbai train stop into one small reason to go outside.

Platform to Park combines verified community data with optional local open-weight generation:

OpenStreetMap supplies the station and nearby public green space.
iNaturalist supplies research-grade observations around that space.
The app always creates a grounded outdoor mission from those facts.
If Ollama is available, a local model rewrites it into a more distinctive mission.
The user closes the screen and takes the detour.

Pocket Mode can optionally read the finished mission aloud with ElevenLabs, so the user can put their phone away sooner. The app still works fully without it.

The model is deliberately prevented from inventing routes, access information, or species. It writes only from the open data supplied in its prompt.

Why open innovation matters

The selected station and generated mission never need to be sent to a proprietary AI provider. The core open-data…

View on GitHub

How I Built It

I built Platform to Park with Next.js, TypeScript, Gemma 3 through Ollama, OpenStreetMap, and iNaturalist. Each piece has a deliberately small role.

OpenStreetMap supplies the place: The app uses mapped green spaces near supported stations. It links back to the source so users can inspect the place themselves.
iNaturalist supplies the observation context: Nearby research-grade observations give the mission something concrete to draw from. They describe what has been recorded around the area—not what the app can promise you’ll see today.
Gemma supplies the invitation: I use gemma3:1b locally through Ollama to turn those facts into a short headline, an outdoor action, and a noticing prompt.

The model receives the station, green-space name, straight-line distance, and available observation names. Its instructions ask it to stay within those facts and avoid inventing routes, opening hours, access information, or species. That boundary matters. A pleasant sentence is useful. A confidently invented shortcut is not.

The distance display is also labelled as a straight-line map estimate. Mumbai’s streets, entrances, crossings, and access rules deserve more respect than a line between two coordinates.

One lesson from building this was that open data still needs checking. Some station queries worked while others failed. I added discovery and verification scripts to check candidates against the data sources rather than filling the dropdown with names that looked convincing.

On the deployment side, the repository includes a Render Blueprint for the Next.js service, with environment configuration and a health-check endpoint. Gemma runs in the local setup. The public deployment uses the open-data fallback unless a reachable Ollama service is configured. I wanted visitors to be able to try the idea without installing a model first.

Why Does Open Innovation Matter?

For this project, openness affects what I can build and what someone else can change.

The map comes from community mapping. The biodiversity context comes from people recording the living world around them. Gemma lets me work with an open-weight model on my own machine. Together, those pieces let me connect a familiar station to a place and an observation without asking a model to make up the city.

Local inference also means the mission-generation step can run without sending its prompt to a proprietary AI provider. I can inspect the prompt, change the instructions, or swap the model through configuration. That flexibility is useful for a small project. I can experiment with how a mission sounds without making every rewrite a paid API call. Someone extending the app can try another model or adapt the experience for another city.

There are limits worth being clear about: the app fetches map and observation data online, so it isn’t an offline trail guide. Optional ElevenLabs narration sends the finished mission text to that service.

But the central idea remains portable: community data gives the model its grounding, and local open-weight inference turns that grounding into something a person might actually want to do.

The data tells me what’s nearby. Gemma helps me find a reason to notice it.

Prize Categories

Best Use of Gemma

Platform to Park uses Gemma 3 through Ollama to generate concise outdoor missions grounded in retrieved map and biodiversity data. Its role is to turn a place and a set of observations into a small, specific invitation to go outside. The local setup makes that generation inspectable, replaceable, and runnable without a proprietary inference API.

Best Use of Render

Platform to Park includes a Render Blueprint for hosting the Next.js application and its server routes, with environment configuration and a deployment health check.

Deployment: platform-to-park.onrender.com

My Colleague Was Tired of Saying “Paneer Bhaji Again” to His Maid. So I Built a Local AI Menu Planner.

Kaustubh Jogle — Sun, 04 Oct 2026 19:36:27 +0000

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

What I Built

A colleague from my office lives alone and has a maid who cooks at home.
The problem was not that food was unavailable. His fridge usually had eggs, paneer, spinach, chicken, onions, tomatoes, and the usual basics. The problem was deciding what to make.

Most evenings ended the same way:

“Paneer bana dete hain.”
“Egg bhurji kar lete hain.”
“Chicken curry?”

After a few weeks, even good food starts feeling repetitive.

So I built Aaj Kya Banega, a local AI kitchen companion that recommends meals based on what is already in the fridge, what you've cooked recently, and how much time you have.

The app lets him:

Track ingredients currently available at home
Add common items or custom ingredients
Get recipe suggestions ranked by ingredient match
Ask a local AI model for fresh meal ideas
Avoid repeating recently cooked dishes
Save recipes and mark meals as cooked
Keep fridge data, preferences, and cooking history

The core question is simple:
What can I make today without getting bored of eating the same thing again?

Demo

aaj-kya-banega-steel.vercel.app

Code

Kaustubhjogle / AajKyaBanega

Aaj Kya Banega?

A local-first meal planner for the daily question: what should we cook today?

Built for a colleague who lives alone and was tired of deciding what to tell his maid to cook every day. With a full fridge but the same paneer bhaji appearing again and again, he needed more than another recipe website. He needed a simple, private way to decide tomorrow's meal.

Add what is in the fridge, explore recipes that fit, shuffle tomorrow's menu, and keep a lightweight record of what was cooked.

What it does

Search common ingredients or add any custom item
Track available fridge items and quantities
Rank recipes by ingredient match
Shuffle tomorrow's menu for fresh options
Save recipes, view cooking steps, and log cooked meals
Keep data in browser localStorage, with no account required
Support light and dark themes

Run locally

npm install
npm run dev

Open http://localhost:3000.

…

View on GitHub

How I Built It

Aaj Kya Banega is built with:

Next.js
TypeScript
Tailwind CSS
localStorage for local app data
Ollama for local AI inference
Gemma 3 as the open-weight recommendation model

The app has two layers of recommendation.
First, it uses a regular ingredient-matching system to identify recipes that already fit what is in the fridge. This is quick, predictable, and useful even without generating anything.
Then, Ollama runs Gemma 3 locally to make the recommendations more personal. The model receives a focused kitchen context:
Available ingredients:
Eggs, paneer, spinach, onion, tomatoes, green chillies

Recently cooked:
Egg bhurji, paneer butter masala

Preferences:
Quick Indian home-style dinner for two people.
Avoid repeating recent meals.

Suggest exactly three meal ideas.
Clearly mention what is already available and what needs to be bought.
Keep the cooking instructions simple.
Return structured JSON only.

The model returns structured recipe data that the app can display cleanly:

{ "title": "Palak Paneer with Roti", "whyItFits": "Uses spinach and paneer already available at home.", "availableIngredients": ["spinach", "paneer", "onion", "garlic"], "missingIngredients": ["cream"], "prepTime": "30 minutes", "maidInstruction": "Make palak paneer with roti for two people. Keep it mildly spicy." }

This keeps the AI useful without letting it become a vague chat interface.

Why Does Open Innovation Matter?

For this project, open innovation matters because a kitchen is personal.

A fridge inventory may sound harmless, but it can reveal habits, food preferences, budgets, dietary restrictions, and daily routines. My colleague should not need to send all of that to a cloud API just to decide dinner.
With Ollama and Gemma 3 running locally:

The meal recommendation flow works without an API key.
Fridge data and cooking history stay on the user’s machine.
The model can run without depending on an internet connection.
The recommendation behavior can be changed by editing a prompt.
A different open-weight model can be swapped in later.
There is no per-request cost for every dinner decision. A closed API would have been faster to connect, but it would make the product dependent on a provider, a network connection, and recurring usage costs. For a small tool built for one person, local AI felt like the better fit.

What’s Next

The next feature is a WhatsApp or SMS handoff.

Once a recipe is selected, Aaj Kya Banega should create a short cooking message that can be sent directly to the maid:

Today: Palak Paneer with Roti
For: 2 people
Use: spinach, paneer, onion, garlic
Buy: cream
Please make it mildly spicy.

The current version already supports generating this instruction locally. The next step is connecting it to a messaging provider.

I also plan to add:

Allergy and dietary preference support
Better ingredient substitutions
Weekly meal variety planning

Prize Categories

Best Use of Gemma

Aaj Kya Banega uses Gemma 3 running locally through Ollama to recommend practical meals from ingredients already available at home. The model considers fridge inventory, recently cooked meals, cooking time, and dietary preferences while keeping the recommendation flow private and local.

My Portfolio Site Was Invisible to AI. Here's What Fixed It.

Kaustubh Jogle — Sun, 28 Jun 2026 17:17:15 +0000

I built my portfolio site as a slick React SPA with a hero section, smooth scroll-spy navbar, the works. Looked great in a browser. Then I ran an framer AEO report.

27 out of 100. Bottom 25%.

The diagnosis was blunt: "AI can't understand this site yet. The site lacks essential text content."

Turns out, I'd built a site that was beautiful to humans and completely invisible to machines. Here's how I took it from 27 to ~85 in a single afternoon and what I wish I'd known before I started.

Wait, What's AEO?

AEO stands for AI Engine Optimization, think of it as SEO that specifically cares about how AI systems (ChatGPT, Gemini, Perplexity, Claude) understand and cite your content. It scores across four categories:

Findable — Can crawlers discover your pages?
Quotable — Is there enough real text to quote?
Understandable — Does the page have structured meaning?
Trustworthy — Does the content link to credible sources?

My site was mediocre on the first two and zeroed out on the last two. Cool.

The Root Problem: SPAs Are Invisible by Default

Here's the thing nobody tells you when you ship a Vite + React SPA: AI crawlers don't execute JavaScript. They see your index.html, which in my case looked like this:

<body>
  <div id="root"></div>
  <script type="module" src="/src/main.tsx"></script>
</body>

That's it. That's what GPTBot, ClaudeBot, and PerplexityBot see in an empty div. My entire portfolio experience, projects, skills, and education existed only in a JavaScript-rendered DOM. To a crawler, my site was a blank page with a title.

The Fixes, Category by Category

Findable: The Low-Hanging Fruit (+14 points)

Two files I simply didn't have:

sitemap.xml — A single-page portfolio only needs one <url> entry. Took 30 seconds.

Canonical URL — One <link> tag in <head>. Without it, AI treats kaustubhjogle.site, www.kaustubhjogle.site, and kaustubhjogle.site/ as three different pages.

<link rel="canonical" href="https://kaustubhjogle.site/" />

I also updated robots.txt to explicitly welcome AI crawlers. The default User-agent: * / Allow: / technically works, but naming them directly GPTBot, ClaudeBot, PerplexityBot, Google-Extended signals intent.

Quotable: The Big One (+14 points)

This was the category that hurt the most, because the fix forced me to confront an uncomfortable truth: my entire site had zero words of readable text as far as crawlers were concerned.

The solution? A <noscript> block. I wrote 500+ words of semantic HTML that mirrors my portfolio content, full of sentences about my experience, skills, projects, and education. It's invisible to JavaScript-enabled browsers but fully readable by crawlers.

<noscript>
  <main>
    <h1>Kaustubh Jogle — Software Engineer</h1>
    <section>
      <h2>Professional Experience</h2>
      <!-- ... Portfolio content -->
    </section>
    <!-- ... full portfolio content continues -->
  </main>
</noscript>

This felt redundant. It is redundant. But it's also the difference between "AI can't understand this site" and "AI can quote you accurately."

I also added a FAQ section, both as a React component and in the <noscript> fallback. Questions like "What technologies does Kaustubh work with?" with proper answers. This maps directly to how people ask AI assistants about developers.

Understandable: Structure Over Style (+18 points)

My hero section had two <h1> tags, one for "KAUSTUBH", one for "JOGLE". Looked sick visually. Terrible semantically. Merged them into a single <h1> with <span> children:

<h1 className="display-giant ...">
  <span>KAUSTUBH</span>
  <span>JOGLE</span>
</h1>

Same visual result. Correct heading hierarchy.

The biggest win here was JSON-LD structured data. I added three schemas to <head>:

Person — name, jobTitle, worksFor, alumniOf, sameAs (GitHub, LinkedIn), knowsAbout
WebSite — basic site metadata
FAQPage — all my FAQ question-answer pairs

This is the most reliable way for AI to understand what your page is about, not just that it exists.

I also filled in the OG tags I'd left empty: og:description, og:url, og:image. These weren't just empty strings; they were literally content="". Cringe.

Trustworthy: Links Actually Matter (+25 points)

This was the category I was scoring 0/25 on. The fix was straightforward but required touching almost every component.

Internal contextual links (nav and footer links don't count):

Hero tagline → "See my work experience →" linking to #experience
Experience description → "View my full tech stack →" linking to #tech
Skills section → "explore my projects →" linking to #projects

External citation links:

Education institutions → linked to tsec.edu and sbmp.ac.in
Project links changed from icon-only to visible text: "View Source" and "Try it Live"

The key insight: body links signal authority, nav links don't. The AEO checker specifically ignores navigation and footer links.

Finally, I created an llms.txt file, an emerging standard (like robots.txt but for AI) that describes your site in plain markdown. It's a bonus check that won't penalize you if missing, but adds points if present.

What I'd Do Differently

Start with the <noscript> block. If you're building a client-rendered SPA, write your noscript fallback first. It forces you to think about your content as plain text before you think about animations and layouts.

Don't treat meta tags as an afterthought. Those content="" empty strings? They shipped to production. For months. Embarrassing in retrospect, but incredibly common.

JSON-LD is not optional anymore. It used to feel like bonus points for SEO nerds. Now it's the primary way AI systems categorize your content. For a portfolio site, the Person schema alone does heavy lifting.

The Scorecard

Category	Before	After
Findable	11/25	25/25
Quotable	11/25	25/25
Understandable	5/25	25/25
Trustworthy	0/25	10/25
Total	27/100	85+/100

The Takeaway

AEO isn't some mystical new discipline. It's the stuff we've always known we should do: semantic HTML, proper meta tags, structured data, meaningful links, but skip because "it works in the browser."

The browser isn't the only consumer of your HTML anymore. AI is reading your markup right now, and it's grading you on whether you made it easy or impossible to understand.

For SPAs specifically, your framework renders beautiful UI. Your index.html renders nothing.
Bridge that gap, and you'll go from invisible to quotable.