DEV Community: Oleksandr Dmytruk

I got tired of staring into the fridge, so gemma3:4b does it for me

Oleksandr Dmytruk — Fri, 23 Oct 2026 14:22:20 +0000

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

What I Built

Fridge to Dinner. You take a photo of your open fridge, it lists what it thinks is in there, you fix the list, and you get three dinner ideas with five steps or fewer each. No meal plan, no shopping list, no account.

The idea came from a lazy week. I didn't want to spend my evenings staring into the fridge, trying to figure out what to cook. I wanted something to take that small but annoying decision off my hands, so I built it.

It runs locally on my machine through Ollama with gemma3:4b. The photo never leaves my laptop.

Demo

Code

runpy21 / fridge-to-dinner

Fridge to Dinner

Take a photo of your open fridge or pantry. Get three different dinners that need few steps and use mostly what's visible (plus salt, pepper, oil and water).

Built for the Hacktoberfest Open-Source AI Challenge, theme Slow and Steady reward laziness. No shopping list, no meal plan, no account. Just dinner.

Everything runs on your machine through Ollama with an open-weight vision model. 100% local. Your photos never leave your machine.

How it works

Two model calls, same local model, nothing stored in between.

Look. You drop in a photo, take one, or choose one from your library Take a photo asks for the camera on https. On http it does not open the camera; it shows “For security reasons the camera is not available. Choose a photo from your gallery or files.” and scrolls to it. The browser shrinks the photo to max 1024 px…

View on GitHub

How I Built It

Model: gemma3:4b through Ollama. It's a multimodal model that runs locally. My hardware is a Ryzen 7 5800X3D, an RTX 3070 Ti, and 16 GB of RAM.

Stack: FastAPI with two endpoints and one static HTML file for the UI. No frontend framework. I built it with Cursor: I wrote the specs and prompts, it wrote most of the code, and I read and tested what came out.

Two model calls instead of one:

Look. The browser shrinks the photo to 1024 px, FastAPI sends it to Ollama's /api/chat with a JSON schema, and the model returns the ingredients it thinks it can clearly see. Anything it's unsure about goes into a separate maybe list.

Cook. The confirmed ingredient list goes back as text only. The model returns exactly three different dishes, each with a cooking time, at most five steps, and a missing list for anything the dish needs that isn't in the fridge.
Why the ingredient list is editable.

The model doesn't always get things right. One time, it identified yogurt as milk. That's a small mistake, but it matters when the next step is generating a recipe based on those ingredients.

So I added a way to correct the list between the two model calls. Ingredients appear as chips: click × to remove a wrong guess, click + to confirm a "maybe", or type in something the model missed.

This way, I don't have to accept everything the model says. I can correct its mistakes before they affect the recipes.

The recipe that surprised me.

One of the suggestions was a salad with yogurt, cucumber, and pesto. It's a simple combination, but not one I would necessarily have thought of myself. I actually made it after a coding session.

That's the kind of result I wanted from this project. Not a complicated meal planner, just a little help finding something different to eat with what I already have.

Smaller details: schema-constrained output keeps the JSON valid, a "show me 3 different ideas" button passes the dishes already shown so the model doesn't repeat itself, saved recipes live in localStorage, and the UI supports English, German, and Ukrainian.

I tested all three languages. The results aren't perfect, but they're reasonably good across them.

The camera button only works over HTTPS, so on plain HTTP it falls back to the file picker.

The version I threw away.

My first idea this week was a to-do triage tool that told you which tasks you could safely skip. A small model had to decide what was urgent and do date math. It told me my passport renews automatically and that a Monday deadline would solve itself.

I patched it with keyword rules, got 10 out of 10 on my own test list, and realized that only proved I'd fitted the rules to my 10 items. I wrote a 50-case evaluation and got roughly 80%. Going from the 3B to the 7B model changed almost nothing. I deleted the project.

What I took from it: small open models can be useful for looking at things and generating text, but I wouldn't trust them blindly with decisions that require careful reasoning or calendar math.

Fridge to Dinner gives the model a narrower job: recognize ingredients, then suggest recipes. And it lets the user correct the first step before moving on to the second.

Why Does Open Innovation Matter?

Privacy. A fridge photo shows more than food: the kitchen, the counter, sometimes a window or a person in the background. I don't want to send that to an API I don't control.

Offline and free. After ollama pull gemma3:4b, there's no API key, no usage quota, and no need to send photos to an external service. Running the model still uses electricity and your own hardware, but there's no per-request API bill.

You can experiment with the model. I also tried gemma3:12b, and it handled my use case reasonably well. Having the option to try a different model without rebuilding the whole application is one of the benefits of running it locally.

Where a closed model would have been better. Honestly, probably accuracy and speed. A hosted frontier model might recognize labels and ingredients more reliably. For a dinner suggestion, I'll take a local model and a few corrections over sending my fridge photos to an external API.

The Lazy Payoff

I built this because I was tired of spending time deciding what to cook. After a coding session, I used one of its suggestions to make a salad with yogurt, cucumber, and pesto.

It wasn't a complicated recipe, and that was the point. I wanted something easy that I probably wouldn't have thought of on my own.

The app doesn't need to solve cooking. It just needs to get me from "there's food in the fridge" to "I know what I'm having for dinner."

Prize Categories

Best Use of Gemma: The whole project runs on gemma3:4b locally, for both the vision step and the recipe step. I also tested gemma3:12b to see how another model size handled the same use case.

The project is open source, runs on your own hardware, and gives users a way to correct the model instead of blindly trusting its predictions.

That's the idea behind Fridge to Dinner: a small, practical use for an open model that makes one everyday task a little easier.

My Friend Couldn't Understand His Favorite Streamer — So I Built This

Oleksandr Dmytruk — Sun, 04 Oct 2026 19:51:16 +0000

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

What I Built

My friend Denis doesn't speak much English, but there's a streamer he really enjoys watching.

He mostly discovers the streamer's clips and highlights on Instagram, but because they're in English, he can't always understand what's happening.

One day, he asked me:

"Could you make something that translates these videos for me?"

So I did.

I built Video Translater — an open-source AI-powered application that takes a video, understands the speech, translates it into another language, generates new speech, and synchronizes the translated audio back with the original video.

The idea is simple:

Take a video Denis can't understand → turn it into a video he can actually enjoy.

And that's how this project started.

Not with a business idea.

Not with a startup pitch.

Just a friend who wanted to watch his favorite streamer.

🎬 How It Works

Video translation sounds simple until you actually try to make the result feel like a real video.

The application turns the process into a pipeline:

Video
  ↓
Extract Audio
  ↓
Speech-to-Text
  ↓
Detect / Select Language
  ↓
Translate
  ↓
Text-to-Speech
  ↓
Synchronize Audio
  ↓
Render Final Video
  ↓
Translated Video 🎥

The important part is that the generated voice has to respect the original video's timing.

For example, imagine someone says something that lasts 4 seconds in English.

The translated sentence might take 6 seconds to say.

If we simply replace the audio, the translated voice will no longer match the video.

So the application compares the generated speech duration with the original timestamp and adjusts the audio when necessary.

That's where a simple "AI translation demo" turns into a real multimedia engineering problem.

🎥 Demo

Watch the demo:
👉 https://www.youtube.com/watch?v=4_827OMZHeY

The demo shows the complete workflow from the original video to the translated result.

The most important thing to see is not just the translation itself, but the final synchronized audio.

💻 Code

The entire project is open source:

👉 https://github.com/runpy21/video-translater

You can explore the complete implementation, run it yourself, open issues, and contribute improvements.

🧠 How I Built It

I built Video Translater around a modular processing pipeline.

The application separates video processing from the AI components so that individual parts can evolve independently.

The main pieces are:

Python — application logic and orchestration
FFmpeg — audio/video extraction, processing and rendering
yt-dlp — video downloading
Speech recognition — converting speech into text
Translation — converting the transcript into the target language
Text-to-speech — generating the translated voice
Audio synchronization — fitting generated speech back into the original timeline

I wanted the AI components to behave like replaceable building blocks rather than creating one giant piece of tightly coupled code.

That makes it much easier to experiment with different models and approaches.

⏱️ The Interesting Engineering Problem

The hardest part wasn't actually translating the words.

It was making the translated speech fit the video.

Suppose the original speech segment is:

|--------- 4 seconds ---------|

But the translated speech takes:

|-------------- 6 seconds --------------|

Simply cutting the audio would make the sentence incomplete.

Simply letting it play would make it overlap with the next segment.

So the pipeline needs to reason about the timeline:

Original timestamps
        ↓
Translated text
        ↓
Generated speech
        ↓
Measure duration
        ↓
Compare with available time
        ↓
Adjust when necessary
        ↓
Place back on timeline

This was one of my favorite parts of the project because it required combining AI output with traditional audio/video engineering.

The AI generates the content.

The rest of the system has to make that content actually work.

🎯 Built for a Real Problem

One of the things I liked most about this project is that I didn't have to invent a use case.

Denis actually asked for it.

He didn't ask for an AI demo. He didn't care which model I used or how the pipeline was implemented.

He just wanted to understand the videos of a streamer he likes.

That gave me a very clear goal:

If Denis can watch the translated video and understand what is happening, the project works.

This also influenced how I built the application.

I focused on the complete experience rather than just getting a translation from an AI model:

video → speech → translation → generated voice → synchronized video

The AI is only one part of that pipeline.

The real challenge was turning the AI output into something that can actually be watched.

🌍 Why Open Innovation Matters

This project is a good example of why I think open innovation matters.

A closed API can make it easy to call an AI model.

But an open ecosystem gives developers much more freedom.

I can experiment with different components.

I can replace a model.

I can run parts of the pipeline locally.

I can inspect how everything works.

I can change the synchronization logic.

I can optimize the application for a specific use case.

And most importantly:

someone else can take this project and improve it.

Video Translater isn't built around one magical AI endpoint.

It's built around a pipeline of components.

That means when better open models become available, the project doesn't have to start from zero.

The building blocks can evolve.

That's what open innovation means to me:

Don't just give developers an answer. Give them building blocks they can turn into something new.

❤️ Why I Built It

This project is personal because the original feature request came from a real person.

Denis didn't ask me to build an AI project.

He didn't care which model I used.

He didn't care about the architecture.

He just wanted to understand what his favorite streamer was saying.

That changed the way I approached the project.

Instead of asking:

"What impressive AI demo can I build?"

I asked:

"What can I build that would actually make someone's life a little easier?"

And that made the project much more fun to work on.

Every feature had a reason.

Translation wasn't enough.

The audio needed to work.

The timing needed to work.

The downloaded video needed to be handled safely.

The whole pipeline needed to produce something Denis could actually watch.

🚀 What's Next?

This is still the beginning.

There are a lot of things I'd like to add:

🎙️ Better voice preservation
👥 Multiple-speaker detection
🗣️ Better speech prosody
📝 Automatic subtitles
🌍 Multiple target languages
📊 Better processing progress
⚡ Improved error recovery
🐳 Easier deployment
🔐 Authentication and rate limiting
☁️ Scalable processing

And I'd love to see other developers take the project in directions I haven't thought of.

🏗️ What I Learned

I started this project thinking I was building a video translation tool.

I ended up learning that AI is only one part of the problem.

A model can generate a translation.

But then you still have to ask:

Does the audio fit the timeline?

Can the video be processed safely?

What happens when something fails?

Can another developer understand the code?

Can the components be replaced?

Does the final result actually solve the user's problem?

That's probably the biggest lesson I took away from this Hacktoberfest project:

Getting AI to produce an output is easy compared to making that output useful.

🏆 Prize Categories

Overall Hacktoberfest Weekend Challenge

🙌 Final Thoughts

A few hours ago, this was just a request from a friend.

Now it's an open-source project.

That's one of the things I love about building software.

A small problem experienced by one person can become an idea that other people can use, improve and build on.

Denis wanted to understand his favorite streamer.

So I built a translator.

Maybe someday, someone else will use it to understand a documentary, a tutorial, a lecture, or a creator from another part of the world.

One video. Different language. Same experience. 🌍

If you find the project useful, feel free to:

⭐ Star the repository
🐛 Open an issue
💡 Suggest an improvement
🔧 Contribute

GitHub: https://github.com/runpy21/video-translater

Thanks for reading — and happy Hacktoberfest! 🚀