DEV Community: Ohm Anand

OrderMint: Turning Customer Chats into Orders with Local AI

Ohm Anand — Sun, 18 Oct 2026 18:04:35 +0000

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

What I Built

OrderMint — Local-First AI Order Management for Small Sellers

Small businesses often receive orders through WhatsApp messages, Instagram DMs, and other informal conversations. Turning these messages into structured orders, checking quantities, calculating totals, and preparing bills manually takes time and can lead to mistakes.

I built OrderMint to simplify that workflow.

A seller can turn an informal customer message into a structured order draft, review the extracted items, correct details, and approve the order before generating a bill.

Key features include:

AI-assisted extraction of products, quantities, and order notes.
Product catalog matching and deterministic validation.
Human review before order approval.
SQLite-backed order persistence.
Printable bills and daily order summaries.
Local AI inference with a fallback when the model is unavailable.

Who would pay for it? Home bakers, tiffin services, cloud kitchens, and Instagram sellers who want a simpler way to manage incoming orders without adopting an expensive, complicated system.

Demo

Hosted application: https://ordermint-nw7h.onrender.com

The hosted frontend is currently experiencing a deployment issue, so the live interface may not load correctly. I’m working on resolving it rather than presenting a broken demo as functional.

For now, you can inspect the source code below. If a working local demo recording is available, I’ll add it here.

Code

GitHub repository: https://github.com/ohm-7643/OrderMint

The project is built with React, Vite, Node.js, Express, and SQLite. The repository contains the application code and setup instructions.

How I Built It

I built OrderMint using Qwen3-8B, an open-weight model running locally through Ollama.

The architecture consists of:

Frontend: React + Vite
Backend: Node.js + Express
Database: SQLite with better-sqlite3
AI inference: Qwen3-8B through Ollama
Validation: Deterministic checks and fallback logic

The model assists with interpreting customer messages, while application logic validates the output and checks it against the product catalog. The seller remains responsible for reviewing and approving the final order.

I also added automated tests and synthetic order-evaluation cases to check application behavior.

One important design decision was to avoid making the AI model the sole authority for business-critical data. The model helps interpret the message, but validation and human approval remain part of the workflow.

Why Does Open Innovation Matter?

Open innovation made it possible for me to experiment with a capable language model locally without building the entire product around a paid, proprietary inference API.

Using an open-weight model through Ollama gave me more control over the inference environment and allowed me to explore a local-first approach to customer-order processing.

It also made the project easier to experiment with as a student developer working with limited resources. I could focus on the actual product workflow — extraction, validation, persistence, and review — instead of depending entirely on a closed API.

Open-source tools across the stack made it possible to build and test the application using technologies that other developers can inspect, learn from, and extend.

Prize Categories

I’m submitting OrderMint for the Side Hustle challenge.

The project explores a practical business use case for open-source AI: helping small sellers spend less time managing orders and more time serving customers.

What’s Next

My next priorities are to resolve the hosted frontend issue, test the workflow with actual small-business sellers, improve extraction accuracy using real feedback, and evaluate whether the tool can save enough time to justify a paid product.

I’d especially appreciate feedback from people who manage orders through chat messages and want a simpler workflow.

A Map Is Evidence, Not an Answer: Building Ghost Shore for 1850s Bengaluru

Ohm Anand — Sun, 11 Oct 2026 18:25:10 +0000

Submission for the Hacktoberfest Open-Source AI Challenge — Week 1: Touch Grass.

What if an old map could help us investigate the city we walk through today?

Imagine looking at a map from the 1850s. You notice a label, a strange outline, or a patch of hatching. You wonder whether it represents a water body, an old tank, or a landscape feature that no longer exists.

It's tempting to jump straight to the answer.

But a historical map is not ground truth. A plausible interpretation is not a verified discovery. And an AI assistant that sounds confident can make the gap between the two even harder to see.

That is the problem behind Ghost Shore.

Ghost Shore is an evidence-first historical map explorer for a c.1854 Plan of Bangalore. It combines a feature catalog, a source-grounded research assistant, and a field expedition companion designed to take research beyond the screen.

The central idea is simple:

AI should help us ask better questions about the real world—not manufacture certainty.

Project: Ghost Shore on GitHub

Live demo: https://ghost-shore-r449.onrender.com

Why build this?

Historical maps are fascinating because they show us a different version of a place we think we know.

But comparing an old map with a modern city involves several difficult questions:

What does the historical document actually show?
How reliable is its alignment with modern geography?
Which interpretations are supported by evidence?
What additional sources or observations would help us investigate them?

I wanted to build a tool that keeps those questions visible instead of hiding uncertainty behind an attractive visualization.

Ghost Shore does not claim to have discovered a vanished lake, reconstructed a lost landscape, or proved that a historical feature survives today. Its three cataloged candidates remain marked pending_human_review.

That distinction is intentional.

What I built

1. An interactive historical map explorer

The frontend uses vanilla HTML, CSS, and JavaScript, with a lightweight Python backend.

The viewer is designed around image-pixel coordinates rather than pretending that every point on an old map can be placed accurately on a modern street map.

The original historical scan is currently excluded from the public repository while its redistribution rights are being verified. Consequently, a fresh deployment or clone may not have access to the scan. The repository documents this limitation rather than substituting an invented historical image.

2. A catalog that preserves uncertainty

Ghost Shore stores candidate features in JSON and validates their structure against a JSON schema.

Each candidate can carry its own evidence, provenance, uncertainty, and review status. The catalog supports searching, filtering, and inspecting individual candidate dossiers.

A label printed on a historical map is an observation about a document. It is not, by itself, proof of a feature's exact identity, extent, or present-day existence.

That difference matters when building tools for historical research.

3. An AI research assistant with explicit limits

The assistant is designed to work with a candidate record and source excerpts supplied to it.

Its documented validation checks include rejecting unsupported verbatim claims, unsupplied coordinates and URLs, and claims that a feature has disappeared. These are safeguards, not a guarantee that every possible error or misleading interpretation will be caught.

The project has two paths:

Mock mode: deterministic, offline behavior that does not require a model API request.
Live mode: an implemented integration with Thinking Machines Tinker, intended to use a language model.

An important limitation: I have not verified successful live inference end to end. The web interface uses the mock path by default, so a response shown there must not be mistaken for a live model-generated result. I have not trained or fine-tuned a model.

I prefer to make that limitation explicit rather than claim an AI capability I haven't demonstrated.

4. Touch Grass: taking research outside

The field expedition companion connects desk research with structured observations in the real world.

It includes:

A 12-item observation checklist.
Browser-local notes saved using localStorage.
A printable field worksheet.
Safety guidance for daylight observations from public places.

The checklist covers topography, visible surface infrastructure, ecological and heritage indicators, and questions that may need further archival research.

The safety rules are part of the design: stay on public paths, never trespass, and never enter storm drains, canal beds, construction sites, or dangerous terrain.

Most importantly, an observation is not proof. A depression in a street, an unusual road name, or a visible drain cannot independently establish that a particular historical feature existed there.

The goal is to gather better questions and observations—not to force a discovery.

The uncomfortable engineering decision: don't fake precision

I experimented with georeferencing the historical sheet using ground control points.

The recorded trial had an RMSE of approximately 87.63 metres. The candidate regions also lie outside the area covered by those control points, meaning their locations would require extrapolation.

That makes a confident modern map overlay difficult to justify.

Instead of displaying precise-looking latitude and longitude coordinates, Ghost Shore keeps the candidate geometry in the source image's pixel space.

This is not a solved georeferencing problem. It is a deliberate decision not to present uncertain results as accurate ones.

Sometimes the most useful feature in a research tool is the claim it refuses to make.

What I learned about AI guardrails

A validator can help constrain what an assistant says, but it cannot make the underlying sources trustworthy.

A statement may appear verbatim in a source excerpt and still be used out of context. A source itself may be incomplete or mistaken.

That is why I see the validator as one layer of a research workflow, not an automatic truth detector.

The deterministic mock mode is useful here, too: it allows the offline behavior and validation rules to be exercised without depending on a live model request. The live integration still needs an end-to-end verification.

How it is built

Frontend: HTML, CSS and vanilla JavaScript.
Backend: Python standard-library HTTP server.
Data: JSON feature catalog and JSON Schema validation.
Image tooling: Pillow.
Tests: Python unittest.
AI integration: an offline mock path and an implemented, not yet end-to-end-verified, Tinker integration.

The repository is open source under the MIT license for its code and documentation. The historical scan is a separate asset whose redistribution rights are still being checked.

What changed during challenge week?

Ghost Shore existed before this challenge week, and I want to be transparent about that.

During this week, I focused on preparing the project for public evaluation, reviewing its documentation and limitations, and working toward a deployable demonstration. This is not a claim that the entire project was created from scratch during the challenge.

The challenge has also pushed me to think beyond whether an application runs: can another person understand its limits, inspect its evidence, and use it responsibly?

Try it and contribute

Repository: https://github.com/ohm-7643/ghost-shore-

The repository includes setup instructions, the feature catalog, schema validation, and the offline assistant example. Full map-viewer functionality requires a lawfully reusable copy of the historical scan at the documented path.

Live demo: https://ghost-shore-r449.onrender.com

Contributions that would help include archival sources, better-supported control points, human review of candidate features, tests for the validator, and improvements to the accessibility and usability of the field worksheet.

What's next?

Verify the live AI integration end to end.
Improve georeferencing with additional and held-out control points.
Build a more explicit human-review workflow for candidate features.
Resolve the scan's redistribution rights or find a suitable reusable source.
Test the field worksheet in actual use and improve it based on feedback.

One question for you

If you were building an AI tool around uncertain historical evidence, where would you make it say “I don't know” most clearly—and how would you do that without making the tool useless?

I'd love to hear how other developers approach uncertainty, provenance, and responsible AI in real-world projects.

I built a local AI workout planner for my gym-obsessed friend

Ohm Anand — Sun, 04 Oct 2026 20:47:55 +0000

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

What I Built

My friend Ritesh is a proper gym guy.

He already enjoys lifting and spends a lot of time training, so motivation isn't really his problem.

Structure is.

Some days he'd train chest, another day triceps, and there wasn't always a clear structure for how his muscle groups should fit together across the week.

Legs were another problem. He didn't know many leg exercises, so they were easier to neglect.

So I built LiftMate around that problem.

LiftMate asks for:

Training goal
Experience level
Training days
Session duration
Available equipment
Muscle priorities

It then builds a structured workout around those constraints.

But I didn't want it to be just another app that generates a workout and leaves you there.

The actual flow is:

Plan → Train → Log → Progress

You can start the workout, log every set, complete the session and get a recommendation for what to do next time.

I showed the working version to Ritesh, and the project was built around the way he actually trains rather than around a generic fitness-app idea.

Demo

Watch the LiftMate Demo

The demo shows the complete flow:

Onboarding → Personalized Workout → Local AI Personalization → Active Workout → Set Logging → Completion → Progression

A look inside LiftMate

The screenshots show the onboarding flow, personalized workout, AI explanation, active workout and completed session.

Code

GitHub: https://github.com/ohm-7643/LiftMate

The repository contains the complete LiftMate application, including the frontend, backend, database, workout planner, AI integration and validation logic.

How I Built It

The most important design decision I made was simple:

I didn't let the AI design the entire workout.

LiftMate has a deterministic workout planner that handles the parts that should be predictable:

Exercise selection
Equipment constraints
Muscle-group priorities
Sets and reps
Rest periods
Session duration
Weekly training structure
Progression

Then I added Qwen3-8B, running locally through Ollama.

Qwen has a much smaller job.

It personalizes the workout.

The model can prioritize a couple of exercises based on the user's goals and provide a short coaching note.

The AI response is then validated before it reaches the user.

LiftMate checks that:

The exercises are actually allowed
The user's equipment supports them
There are no duplicates
They fit the planned focus
The prescriptions stay within allowed limits
The response has the expected structure

If the local model fails, times out or returns something invalid, LiftMate falls back to the deterministic workout.

So the architecture is:

User Profile → Deterministic Planner → Qwen3-8B → Validation → Workout

That separation was intentional.

I wanted the model to make the experience more personal without making the whole application depend on whatever the model happens to generate.

Why Does Open Innovation Matter?

I could have called a closed AI API and asked it to generate a workout.

That would have been easier.

But for LiftMate, running an open-weight model locally made more sense.

With Qwen3-8B running through Ollama, the AI personalization can happen on the user's own machine. A fitness profile doesn't have to be sent to a third-party AI provider just to decide which exercises to prioritize.

It also gives me control.

I can inspect the prompts, change the rules, swap the model, or experiment with another open model without rebuilding the whole application around one provider.

More importantly, I don't have to blindly trust the model.

The deterministic planner remains responsible for the actual workout structure, while the model adds personalization on top.

That was probably the biggest thing I learned from this project:

Open-source AI doesn't have to mean letting the model do everything.

For LiftMate:

AI personalizes.

Rules keep it reliable.

My Agent Session

I didn't use DevRelay for this project, so I'm leaving this optional section out.

Prize Categories

No partner category claimed.

sdsdfvdvfrgbt

Ohm Anand — Sat, 03 Oct 2026 08:56:06 +0000