DEV Community: MA10

🧾 ReceiptPocket — Your Expenses, Privately Managed

MA10 — Sat, 17 Oct 2026 16:35:05 +0000

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

What I Built

🧾 ReceiptPocket — Your Expenses, Privately Managed

Receipts pile up. Expense tracking becomes tedious. And using AI to automate it can mean sending sensitive financial information to a service you don't control.

I built ReceiptPocket, a local-first, AI-powered receipt and expense organizer that helps freelancers and small business owners turn receipt images into organized expense records.

The idea is simple: upload a receipt, let AI extract the important details, review the results, and save the expense. Your receipt-processing workflow doesn't need to send your financial documents to a cloud AI service.

What can it do?

AI-powered receipt extraction: Extract merchant names, transaction dates, amounts, and expense categories from receipt images.
Local data storage: Store expenses in SQLite and keep receipt images on your own computer.
Expense dashboard: View spending summaries, recent transactions, and category breakdowns.
Expense management: Search, filter, inspect, and export saved expenses to CSV.
Multi-currency support: Preserve original receipt amounts and currencies, convert supported expenses into a chosen reporting currency, and retain exchange-rate information.
Manual entry: Add expenses manually when OCR or AI extraction needs help.

Who would pay for it?

I built ReceiptPocket with freelancers, independent professionals, and small business owners in mind. These users often need to organize expenses without necessarily needing a complicated accounting platform.

A potential business model could be a low-cost one-time license, optional paid setup, or ongoing support for people who prefer managing their financial records locally instead of depending on a cloud service.

I haven't yet validated willingness to pay with a paying customer. The next step is to get ReceiptPocket into the hands of real users, learn what they need, and see whether it genuinely saves them time.

Demo

🎥 Watch ReceiptPocket in action

Watch the ReceiptPocket demo on YouTube

In this walkthrough, I demonstrate ReceiptPocket's local AI receipt extraction, expense saving, and expense management workflow.

Code

💻 GitHub repository: ma10-yt/ReceiptPocket

The repository contains the Python application, dependencies, setup instructions, configuration, and MIT License.

How I Built It

ReceiptPocket is built with Python and Streamlit. I wanted to keep it straightforward enough to run locally without building an entire cloud backend.

The technology stack:

Tesseract OCR reads the text on receipt images locally.
Qwen2.5 1.5B Instruct, an open-weight language model, runs locally through Ollama to turn OCR text into structured expense details.
SQLite stores expense records on the user's computer.
Babel handles locale-aware currency formatting.
Frankfurter supplies exchange-rate reference data when currency conversion is needed.

The receipt-processing workflow looks like this:

Upload a receipt image.
Extract its text using local OCR.
Pass the extracted text to the locally running Qwen model.
Parse the response into structured expense details.
Let the user review and correct the values.
Save the confirmed expense to SQLite.
View, search, filter, and export the saved record.

I also implemented manual-entry fallbacks, expense history, multi-currency support, and safeguards around currency conversion and database migrations.

I used GitHub Copilot in VS Code to help build, debug, and refine the application. During development, I worked through practical issues involving Windows OCR configuration, Streamlit reruns, reliable expense persistence, and SQLite locking during currency migration.

Testing the application taught me that getting an AI model to return a response is only one part of building a useful product. The application around it still needs validation, error handling, reliable storage, and safeguards against incorrect AI output.

Why Does Open Innovation Matter?

The central idea behind ReceiptPocket is that automating expense tracking shouldn't require handing your receipts to a cloud AI provider.

Receipts reveal personal purchases and business activity. For freelancers and small business owners, expense records can also contain sensitive commercial information.

ReceiptPocket uses Tesseract and a locally running Qwen model instead of a hosted AI API for receipt processing. The receipt image, OCR text, AI extraction, and expense database stay on the user's computer.

Open-weight models give developers flexibility, too. I can experiment with different local models, assess extraction quality on different receipt layouts, and potentially adapt the workflow without making every request dependent on a particular provider's pricing or API availability.

There is also a practical cost consideration. Once the application and model are installed, local inference avoids per-request charges from a hosted AI inference service, although it still uses the computer's processing power, memory, and electricity.

This approach has trade-offs. A small language model can misread blurry receipts, miss information, or confuse currency symbols. That's why ReceiptPocket lets users review and correct extracted details instead of blindly trusting the model.

The core OCR and AI workflow can operate offline after setup. Initial installation and model downloads require internet access, and obtaining fresh exchange rates can also require a connection. When requesting an exchange rate, the application needs currency-pair and date information; it doesn't need to upload the receipt or merchant details.

For me, open innovation is about giving developers and users greater control over their software, their data, and the technology they choose to build with.

ReceiptPocket is my attempt to apply that idea to a small but practical problem.

Prize Categories

Best Use of GitHub Copilot — $100

I used GitHub Copilot in VS Code to help develop and debug ReceiptPocket, refine application code, and work through implementation issues.

This project gave me an opportunity to use AI-assisted development to build something functional, test the results, and iterate on the code rather than stopping at a prototype.

I'm entering this category based on my use of GitHub Copilot during development.

Thanks for checking out ReceiptPocket! If you're a freelancer or small business owner who deals with receipts regularly, I'd love to hear what you would want from a local-first expense manager.

devchallenge #hf26challenge

Touch Grass 🌳: An AI Scavenger Hunt That Gets You Outside

MA10 — Sun, 11 Oct 2026 07:20:45 +0000

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

What I Built

What if AI gave you a reason to put down your phone and actually go outside?

That's the idea behind Touch Grass, an AI-powered outdoor scavenger hunt that turns your real surroundings into a game.

Instead of giving every player the same fixed list of objectives, Touch Grass uses the player's location and nearby geographic information to generate five objects to find. A player exploring a park might receive different targets from someone exploring a busy residential or commercial area.

Here's how a game works:

Create a game or join your friends using a game code.
Allow location access so the game can understand your surroundings.
Receive five scavenger-hunt targets generated with the help of Gemma and local geographic context.
Head outside, explore, and find the objects.
Take a photo using the in-game camera.
Let the YOLO object-detection model verify the photo.

The first player to verify all five targets wins!

There's also multiplayer gameplay, collaborative target replacement, location-context refreshes as players explore, and optional step-count and distance statistics.

One important design decision was to restrict targets to classes supported by the actual YOLO detector. There's no point asking players to find an object the verification model cannot recognize.

The goal is simple: make the screen the shortest part of the experience.

Demo

🚀 Try Touch Grass here:

https://touch-grass-api-uwhz.onrender.com/

The application is deployed on Render. Open it on your phone, grant location and camera permissions, and try creating a game.

The first visit may take a little time because the free hosting service can spin down when idle. For the best experience, use the deployed HTTPS link so the browser can access the camera and location APIs.

Code

💻 GitHub repository: ma10-yt/touch-grass

The source code includes the FastAPI backend, frontend, AI target generator, geographic context service, YOLO verification pipeline, MongoDB integration, and automated tests.

How I Built It

My main goal was to make AI an actual part of the gameplay rather than simply adding a chatbot to an application.

The project uses:

Python and FastAPI for the backend and game APIs.
HTML, CSS, and JavaScript for the frontend.
MongoDB Atlas for persistent game and multiplayer state.
OpenStreetMap, Nominatim, and Overpass for locality and nearby-feature context.
Gemma for AI-generated targets and hints.
Ollama for local language-model inference during development.
Cloudflare Workers AI for production Gemma inference.
YOLOv8n with ONNX Runtime for server-side photo verification.
Render to host the deployed application.
GitHub Copilot in VS Code to help me write code, debug issues, and iterate on the implementation.

The journey from local Gemma to Cloudflare

One of the most interesting parts of this project was figuring out how to run the language model reliably after deployment.

First, I used Ollama with Gemma 3 1B locally.

I downloaded the model and ran it through Ollama on my own computer. This let me experiment with prompts and build the initial target-generation flow without depending on a hosted inference provider.

However, my production application runs on Render. The Ollama model running on my laptop wasn't automatically available to that remote server. I needed a way to run inference remotely.

Next, I tried OpenRouter.

It gave me access to a hosted Gemma model, so I could connect the deployed backend to a remote inference API. But I ran into free-model rate limits and provider-capacity errors. A game should not become unusable just because a model provider is temporarily unavailable.

Finally, I integrated Cloudflare Workers AI.

I switched production inference to Google's Gemma 4 26B A4B Instruct model:

@cf/google/gemma-4-26b-a4b-it

I tested the REST API, handled the model's response format, disabled thinking mode to avoid wasting the output-token budget on reasoning, and integrated the model into the existing backend.

I also added handling for quota exhaustion, invalid credentials, temporary rate limits, malformed output, and other provider failures. When generation is unavailable, the backend can select eligible targets through its location-ranked fallback rather than blindly relying on a fixed demo list.

The final architecture keeps the AI provider separate from the game logic. Ollama remains useful for local development, while the deployed application can use Cloudflare for remote inference.

Making location actually matter

Getting a model to return five objects was only the beginning. The targets needed to make sense for the player's surroundings.

I integrated OpenStreetMap context into the generation pipeline. The backend retrieves nearby geographic features, classifies the surrounding area, ranks eligible object classes, and includes that context in the model prompt.

During testing, I discovered that map requests could time out and push the generator into a generic-context fallback. Caching could also reuse context for nearby locations. I improved the request timeout, retry behaviour, cache precision, and diagnostic logging to make it easier to distinguish actual location-aware generation from generic fallback behaviour.

I also addressed repetitive target generation and a target-replacement bug. The replacement logic now excludes the class being replaced, so the game doesn't simply offer the same object again.

The backend test suite most recently passed 157 tests, with 2 skipped.

These problems taught me that getting a successful LLM response isn't the same as building a reliable AI feature. Geographic data quality, candidate selection, validation, retry behaviour, and application state all matter.

Why Does Open Innovation Matter?

For Touch Grass, open innovation mattered because I wanted control over how the AI fits into the application.

Using an open-weight model such as Gemma meant I could start locally with Ollama, experiment with prompts, and then move to a hosted inference provider when I needed to deploy the application. I didn't need to redesign the entire game around one provider.

That flexibility was valuable when OpenRouter's free-model limits became a problem. I could test another way of serving Gemma while keeping the same core target-generation and validation logic.

Open innovation also matters for the computer-vision side. The game doesn't blindly trust whatever the language model suggests. The backend constrains target classes, validates generated responses, and uses an actual object detector to check submitted photographs.

There is an important trade-off: production Gemma inference is hosted through Cloudflare, so the deployed application is not an entirely local or offline AI system. The local Ollama setup remains available for development, while production benefits from managed inference. The target-generation prompt and coarse geographic context are sent to Cloudflare, but camera photographs are processed by the application's backend for YOLO verification rather than being sent to the Gemma API.

I also learned that using an open-weight model doesn't automatically make an application reliable or private. The surrounding architecture, the data sent to each service, and the way failures are handled matter just as much.

For me, open innovation meant being able to experiment, change deployment strategies, inspect and improve the application logic, and keep the project adaptable rather than being locked into one AI provider.

And most importantly, it helped me build something where AI encourages people to interact with the world instead of spending more time staring at a screen.

My Agent Session

I used GitHub Copilot in VS Code throughout development to help write code, investigate bugs, and refine the implementation.

I haven't included a DevRelay session link in this submission, but the project source and commit history are available in the GitHub repository.

Prize Categories

I'm entering the following categories based on the technologies used in Touch Grass:

Best Use of Gemma ($200): Gemma generates contextual scavenger-hunt targets and hints. I experimented with local Gemma inference through Ollama before deploying a hosted Gemma model through Cloudflare Workers AI.
Best Use of Render ($200): Render hosts the deployed FastAPI application and frontend, making the game accessible through a public live demo.
Best Use of MongoDB Atlas ($100): MongoDB Atlas provides persistent storage for the game's state and multiplayer sessions behind an application built around an open-weight model.
Best Use of GitHub Copilot ($100): I used GitHub Copilot in VS Code extensively while writing and debugging the project and iterating on implementation and tests.

Thanks to the DEV team and the Hacktoberfest partners for organizing this challenge. Building Touch Grass pushed me to work through real deployment and AI-integration problems, not just get a prototype running locally.

Now it's time to close the editor and touch some grass. 🌳🎮

devchallenge #hf26challenge

I Built an AI Recipe Generator for My Sister 🍳[Hacktoberfest Weekend Challenge: Build for a Friend]

MA10 — Fri, 02 Oct 2026 14:39:57 +0000

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

What I Built

I built an AI Recipe Generator for my sister, who loves cooking but often has trouble finding recipes that match the ingredients she actually has at home.

Her usual process was to search YouTube for a recipe, open a video that looked good, and then discover that it required ingredients she didn't have. Even when she found a recipe she could make, the instructions were sometimes unclear or the recipe simply wasn't what she was looking for.

So I built something that starts with what she already has, instead of making her search through recipes first.

She can either type in her ingredients or upload a photo of them. The AI then suggests five recipes she could make. She chooses one, and the app generates the complete recipe with ingredients, preparation and step-by-step cooking instructions.

It also lets her specify dietary preferences, cuisine, number of servings, and maximum cooking time.

Demo

🌐 Try the live app

The app is deployed on Render and can be used directly in the browser.

Code

GitHub: AI Recipe Generator

The project is built with Python and Streamlit, with the AI functionality handled through Backboard and Kimi K2.6.

How I Built It

I built the application with Python and Streamlit and used Kimi K2.6, an open-weight model, through Backboard and OpenRouter.

The project has two main AI steps.

First, the user provides ingredients either as text, an uploaded image, or both. When an image is uploaded, Kimi analyzes the image to identify the visible ingredients. The application then asks the model for five recipe suggestions rather than immediately generating a long recipe.

Second, the user selects the recipe they want. The application sends that selection back to the AI and generates the complete recipe, including ingredients, timings, substitutions, cooking tips, and step-by-step instructions.

I deployed the application on Render, and used environment variables to keep the Backboard API key out of the source code.

Why Does Open Innovation Matter?

The open-weight model was important because the project is built around an AI model that can understand both text and images while still being part of an open-weight ecosystem.

That gave me the flexibility to build the application around the model rather than tying the entire project to one closed AI provider. It also makes it easier to experiment with different open-weight models and providers through the same architecture.

For this project, that flexibility was especially useful because image understanding is a core part of the experience: my sister can simply take a photo of what she has instead of manually listing every ingredient.

My Agent Session

I did not use DevRelay for this project.

Prize Categories

Best Use of Render — The application is deployed and publicly hosted on Render.
Best Use of Backboard — Backboard is used as the AI interface for the open-weight model powering the application.

Built for my sister ❤️