DEV Community: Shashank Chakraborty

Ofrenda is a local altar for long lost repositories which still have unfinished work.

Shashank Chakraborty — Mon, 26 Oct 2026 21:13:26 +0000

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

Ofrenda

What I Built

Some folders are cemeteries of unfinished work. The last commit is still the inscription on the stone, and nobody has read it in years.

Ofrenda is a local altar for those repositories. You point it at a folder on your machine. Each git repo that went quiet becomes a niche: the years it was alive, how long it has been dark, and its last commit subject. A longer quiet means a lower flame.

Ask one to speak. Gemma 3, running on this computer through Ollama, answers in the repository's voice. It may only use the record it was handed: commit subjects, dates, the author name as git wrote it, a short README, and TODO lines. The server drops any commit id the model invents. If nothing it cited was real, the altar refuses the remembrance and leaves the inscription in place.

The sample grave is hourglass, a tiny duration parser whose last commit is 14 February 2023. On this machine Gemma said:

The parsing of time ceased within these boundaries.

It cited all five commits, from "Start a duration parser for the kitchen timer" through "Leave a warning about months before stopping," and the offering was a real file: test_hourglass.py. It did not invent a person. The ghost is the repository.

Demo

The app runs locally.

ollama pull gemma3:4b
python -m venv .venv
.venv\Scripts\activate
pip install -r requirements.txt
python -m app

Open http://127.0.0.1:8765 and choose Sit with the sample. Or paste a folder that is a repository, or that contains some.

If the 4B model is slow on CPU:

set OFRENDA_MODEL=gemma3:1b

Code

https://github.com/Shashank-blip/Ofrenda

How I Built It

Python and FastAPI serve one page. There is no database and no account. Git is read with git log and a walk for TODO lines. Diffs are not sent. Files named .env, and names that look like keys, are left out of the packet, so a secret in a note does not become part of the prompt.

The model call is Ollama at 127.0.0.1, gemma3:4b, JSON output, and a small context window so a laptop without a discrete GPU can hold it. This machine has Intel Iris Xe graphics. The 4B model still answered.

The check that matters is small and tested without the model: a citation has to match a SHA that was in the packet. Unknown ids are dropped. An empty citation list is a refusal, not a story.

Why open innovation matters

A closed model would have meant uploading unfinished work: half-written TODOs, private commit subjects, the names of the people who touched the code. The dead, in this sense, should be visited at home.

Gemma is an open-weight model. Ollama runs it on the machine. After the weights are downloaded, the altar does not need the network to speak. The weights can be swapped with OFRENDA_MODEL. Nothing about the remembrance is locked inside a hosted service that could disappear and take the voice with it.

Prize Categories

Best Use of Gemma

Lazyyyyy pardons the notes you were never going to read

Shashank Chakraborty — Thu, 22 Oct 2026 22:46:02 +0000

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

What I Built

I do not read the pile. I paste it and close the tab.

Lazyyyyy is that pile. Messages, newsletters, half-plans, the lease you have been circling. You drop them in a box. You get two lines back, and each note gets one stamp:

Pardoned. Nothing breaks if you ignore it.
Two minutes. Someone, or a date, is actually waiting, so it writes the reply.
Already seen. You got away with this shape of thing before. It does not make you decide again.

The person who gets to be lazier is anyone whose unread pile has become a second job. The sample pile is six notes. A raccoon video, a playlist with no date, a morning-routine newsletter, a lease that needs a yes or no by Friday, the same lease again, and Priya, who is blocked until you say whether the demo is Thursday or Friday. The raccoon can wait. Priya cannot. The second lease is not a new problem.

Demo

lazyyyyy.vercel.app

Click Use the sample pile and leave the tab open. The first thing that appears under Already gotten away with is two old pardons: a playlist from Oct 11, and a morning-routine newsletter from Oct 3. Those are planted on purpose. Then the page searches them, and Gemma stamps the six notes. A two-minute stamp includes the reply, with a button to copy it.

The public page calls Gemma through Ollama's hosted API. The vectors come from EmbeddingGemma on a machine I control, because that model is not in Ollama's hosted catalog. If you open a new pile while that machine is asleep, the old pardons are still in Tiger. A fresh stamp needs the tunnel.

Code

Shashank-blip / Lazyyyyy

Lazyyyyy

You paste the messages, notes, and links you are not going to read. Lazyyyyy stamps each one.

Pardoned. Nothing breaks if you ignore it Two minutes. Someone or a deadline is actually waiting, so it writes the reply Already seen. Tiger remembers you already got away with this, or the same ask showed up twice in the pile.

The only thing you are supposed to read is two lines.

Why this is local

The notes people avoid are the personal ones: a lease, a person waiting, a chat they do not want in someone else's log. Gemma 4 E4B runs through Ollama on the same machine as the paste. EmbeddingGemma turns each note into a vector here too. Nothing in the pile is sent to a model API.

Tiger is the memory, not a log bolted on at the end. Every stamp is stored with its text and its…

View on GitHub

github.com/Shashank-blip/Lazyyyyy

MIT. The pile lives in its own Postgres schema, lazyyyyy, so it can share a Tiger service without touching anything else on it.

How I Built It

Gemma does two jobs, and only those. It splits a paste into separate notes. Then, after search, it stamps each note. The prompt forbids a todo list. A date, money, or a named person waiting on a reply cannot be a pardon. A merge has to point at a real earlier note. If a stamp comes back missing, the pile stops and asks you to try again. Quietly pardoning a deadline would be the lazy version of a bug.

Between those two calls, each note is embedded with EmbeddingGemma (768 dimensions) and looked up in Tiger. Keyword rank is BM25 through pg_textsearch. Meaning rank is pgvector cosine distance on a halfvec. The two lists are fused with reciprocal rank fusion, k = 60, and the top three go into the prompt. Exact words like "Friday" and "Priya" survive the keyword side. "Send the playlist whenever" still matches "the playlist when you can" on the vector side.

flowchart LR
  paste[Paste] --> split[Gemma splits the notes]
  split --> embed[EmbeddingGemma]
  embed --> tiger[Tiger hybrid search]
  tiger --> stamp[Gemma stamps verdicts]
  stamp --> lines[Two lines]
  stamp --> memory[Tiger stores the decision]

Vercel hosts the site. It cannot hold Gemma 4 E4B, which is about 6 GB before it even starts. So the deployed app sets OLLAMA_HOST to https://ollama.com and GEMMA_MODEL to gemma4. The same /api/chat call runs against gemma4:e4b on my laptop when OLLAMA_HOST is local. One environment variable swaps them.

Ollama also refuses a public hostname. A tunnel to port 11434 returned 403 until the request's Host header was rewritten to localhost:11434. That is the whole of the deployment trick. The model did not get more clever. The header did.

Why Does Open Innovation Matter?
The notes people avoid are the personal ones. A lease. A person waiting. A chat they do not want in someone else's log.

An open-weight Gemma is what makes the pardon possible without renting a closed chat product for it. On the laptop, gemma4:e4b and EmbeddingGemma run through Ollama, and the pile does not need a model API at all. On the public demo I serve Gemma through Ollama instead, which is still Gemma, still swappable, and still not a closed assistant with a monthly seat. GEMMA_MODEL and OLLAMA_HOST are the whole provider. A bigger local model, or a smaller one, is a config change.

Tiger is the part that gets lazier over time. The stamp is stored with the text and the vector. Next time, hybrid search recalls the old decision and Gemma is not asked to re-litigate it. A closed organizer would call that memory a feature on a higher plan. Here it is a table in a schema I control.

A closed API could sort the same six notes. It would also be the place those notes live, and it would charge me to look at them again tomorrow. The open setup let me keep the judgment, the vectors, and the veto in pieces I can replace.

Prize Categories
Best Use of Gemma. Gemma splits the pile and writes the stamps. Locally that is gemma4:e4b through Ollama. On the deployed site it is gemma4 served by Ollama. EmbeddingGemma, also Gemma, builds the 768-dimension vectors the search uses.
Best Use of Tiger Data. Every note and every stamp is a row in Tiger with a pgvector embedding. Search is hybrid: BM25 keyword rank plus cosine distance, fused with reciprocal rank fusion. The agent reads and writes that database. It does not keep a side file of "memory."

From GitHub Commits to Tasks: Learning Backend Webhooks Through Open Source

Shashank Chakraborty — Thu, 22 Oct 2026 19:12:47 +0000

One of the best ways to learn backend development is to stop treating it as just writing APIs and start understanding how different systems communicate with each other.

Recently, while contributing to DevBoard, an open-source Kanban board built specifically for developers, I worked on a feature that helped me explore exactly that: creating tasks from GitHub commit events using webhooks.

🔗 Project: https://github.com/anoopcodehack/DevBoard

The problem

Developers already spend a large part of their day inside GitHub. Switching between GitHub and a separate task board to keep work organized can introduce unnecessary manual steps.

What if a relevant GitHub event could trigger task creation in DevBoard automatically?

That was the idea behind this contribution.

How webhooks make this possible

A webhook allows one application to notify another when a particular event occurs.

The workflow, at a high level, looks like this:

An event occurs on GitHub. A commit-related event triggers the configured webhook.

GitHub sends an HTTP request to the application's webhook endpoint, including event data in the payload.

The backend receives and processes the event, extracting the information it needs from the payload.

DevBoard creates a task using the relevant information, allowing the event to feed directly into the task-management workflow.

Instead of repeatedly asking GitHub whether something has changed, the receiving application can react when an event notification arrives.

That is what makes webhooks such a useful integration mechanism.

What I learned

This was more than just connecting two applications.

It was an opportunity to understand how backend systems handle external events, how HTTP requests can trigger workflows, and how data from one service can be transformed into something useful in another.

It also made me think more carefully about the details that matter in real integrations: validating incoming requests, handling unexpected payloads, preventing duplicate processing where necessary, and making failures observable.

These are the kinds of engineering considerations that turn a simple integration into a reliable feature.

Why I enjoy contributing to open source

This is one of the reasons I enjoy working on existing projects.

You get to understand a codebase, work on a real issue, see how a feature fits into an existing application, and learn from the process of contributing through pull requests.

I've had 6 PRs merged into DevBoard so far, with another contribution in progress. Each one has been an opportunity to improve something while learning along the way.

The biggest takeaway for me: building backend systems is not only about what happens inside your application. It's also about how your application communicates, reacts, and integrates with the world around it.

I'm looking forward to learning more, building more, and continuing to contribute.

If you're interested in developer-focused open source projects, check out DevBoard:

🔗 https://github.com/anoopcodehack/DevBoard

OpenSource #BackendDevelopment #Webhooks #GitHub #WebDevelopment #SoftwareEngineering #BuildInPublic

DocuFlow: Turning Invoice PDFs into Structured Financial Data with Python and Docker

Shashank Chakraborty — Mon, 19 Oct 2026 22:26:50 +0000

DocuFlow: Turning Invoice PDFs into Structured Financial Data

Invoices are easy to overlook when they’re just files sitting in a folder.

But once you need to extract information from hundreds of documents, identify duplicates, store financial records, and analyze spending, things get more interesting.

That’s the problem I wanted to tackle with DocuFlow — an intelligent, containerized invoice ingestion pipeline built with Python.

Shashank0701-byte / docuflow

DocuFlow is a containerized, event-driven pipeline that automates ingestion, OCR, parsing, and analytics for invoices and financial documents.

DocuFlow — Intelligent Invoice Ingestion Pipeline

DocuFlow is a containerized, event-driven pipeline that automates ingestion, OCR, parsing, and analytics for invoices and financial documents. It uses a lightweight microservice pattern so heavy OCR work runs asynchronously and does not block the UI.

Quick highlights:

Hot-folder watcher for real-time ingestion
Celery + Redis for asynchronous OCR and parsing
Tesseract + Poppler for PDF/image text extraction
PostgreSQL for persistent storage
Streamlit dashboard for visualization and quick analysis

🏗️ Architecture

The system follows a microservices pattern and is orchestrated with Docker Compose.

If GitHub renders the diagram you will see the flow below. If it doesn't, a plain ASCII fallback is provided right after.

graph LR
  A[data_raw_hot_folder] -->|New PDF detected| B[watcher_service]
  B -->|Push task| C[redis_broker]
  C -->|Distribute task| D[celery_worker]
  D -->|Extract text| E[tesseract_poppler]
  D -->|Parse & save| F[postgres_db]
  F -->|Query| G[streamlit_dashboard]

Plain fallback (always visible):

Flow
data/raw (Hot Folder) -> Watcher Service

…

View on GitHub

What does it do?

DocuFlow watches a designated folder for new invoice files and processes them through an asynchronous pipeline.

The workflow looks like this:

New PDF -> File Watcher -> Redis + Celery -> OCR -> Data Parsing -> PostgreSQL -> Streamlit Dashboard

The goal is to turn unstructured invoice documents into structured, queryable financial data without making the dashboard wait for every document to finish processing.

Under the hood

Here are some of the engineering decisions behind the project:

Event-driven ingestion: A folder watcher detects incoming documents and queues them for processing.

Asynchronous processing: Celery and Redis separate the ingestion flow from the OCR workload, making the architecture easier to extend with additional workers.

OCR and parsing: Tesseract and Poppler help extract text from PDFs, while parsing logic identifies fields such as invoice number, date, vendor, and total amount.

Persistent storage: PostgreSQL stores the extracted records for downstream queries and analysis.

Data visibility: A Streamlit dashboard presents spending trends, vendor breakdowns, recent invoices, and processing information.

Containerized services: Docker Compose brings the watcher, worker, database, broker, and dashboard together in a reproducible local environment.

I also worked on duplicate detection so that the pipeline can avoid reprocessing the same invoice unnecessarily.

What I wanted to explore

This project was about more than extracting text from a PDF.

I wanted to work with the pieces that turn a script into a pipeline: asynchronous jobs, service boundaries, persistence, containerization, and visibility into the processing workflow.

It also made me think more carefully about what happens when a document is malformed, OCR produces noisy output, or a parser encounters an unexpected invoice format.

There’s still room to grow — including stronger test coverage, more robust parsing for varied invoice layouts, and better production-grade observability.

What's next?

More resilient extraction for inconsistent invoice formats.
Better automated testing and CI integration.
Email-based invoice ingestion.
Smarter parsing for complex financial documents.
Improved operational visibility and failure recovery.

DocuFlow is an evolving project, and I’m looking forward to improving it further.

I’d especially love feedback from developers who have built document-processing pipelines: What would you improve first — the OCR and parsing layer, task reliability, or observability?

Claude is stuck on a question. Answer it from Discord.

Shashank Chakraborty — Sat, 17 Oct 2026 23:29:03 +0000

Claude Code will happily work for twenty minutes and then stop on a question you could have answered in one line. The terminal is on a desk. You are not.

A few people have already solved the "I'm not at the keyboard" half of this. jagafarm shows that a tmux session is what keeps the agent alive when the laptop lid closes, and that attaching from a phone is the whole trick: Stop losing Claude Code sessions: a tmux primer for mobile devs. coa00 and yuu1ch13 go further and put Allow and Deny on the lock screen, by blocking inside a PermissionRequest hook until ntfy.sh comes back with a decision: a mobile approval system and Approve Claude Code permission requests from your phone. pederaa uses the Notification hook so you at least find out the agent is waiting: How to know when a Claude Code agent needs your approval.

Those are the right shapes for yes and no. They are a bad shape for the message Claude actually sends, which is often three questions with descriptions, or a sentence you still have to type.

agent-bridge takes the tmux half from the primer and the notification half from the hook posts, and then does something they deliberately do not: it types your reply into the live pane. The hook does not wait, and it does not return allow.

Code

Shashank0701-byte / agent-bridge

Get a Discord DM when your coding agent is blocked, reply from your phone, and have it typed straight back into the session. Works with Claude Code, Codex, or anything with a CLI.

agent-bridge

Get a Discord DM when your coding agent (Claude Code, Codex, etc.) is blocked waiting on you, reply from your phone, and have that reply typed straight back into the session -- no need to be at your keyboard.

It types what you send into a live terminal on your machine, so one Discord account is all that stands between a stranger and your shell. Two minutes on Security before you install is time well spent.

How it works

The whole thing hinges on one idea: run the agent inside tmux, then treat the terminal itself as the integration point instead of hooking into each tool's internals differently. That's what makes it work the same way for Claude Code, Codex, or anything else you run in a terminal.

 you AFK                         tmux session "myproject"
   |                                    |
   |  Discord DM  <----- notify.sh <----+  Notification hook fires
   |                                       (Claude Code is

…

View on GitHub

What shows up on the phone

A decision is the whole card, not a buzz that says "something needs you."

You answer with the codes it printed. 1:1 2:1 3:1 means the first option of each question. The bridge turns those numbers back into the labels Claude is waiting for, then confirms what it sent.

Two projects are two tmux sessions. Each message is tagged with the one it came from. A reply to PromptWall never lands in CodePulse.

A permission prompt is the same idea in one line. pick 2 presses the digit. Ordinary prose is typed in as if you were sitting there.

Why it types, instead of approving inside the hook

A PermissionRequest hook can return allow or deny and Claude continues. That is what the ntfy projects do, and it is the right tool when the only decision is a button.

It does not cover the rest of what the pane is showing. A question card wants the option labels. A plan you disagree with wants a sentence. A follow-up wants whatever you would have typed. The terminal already accepts all of those. So the bridge treats the terminal as the API.

The path is short. Claude's Notification hook fires because the agent is blocked. A Discord bot, allowlisted to one user id, DMs you. Your reply is loaded into a tmux paste buffer and pasted into the named session, then Enter. send-keys is the wrong primitive here: tmux parses that text as arguments, so a reply that starts with - is a flag, and quotes get eaten. A paste buffer is just bytes.

The hook itself returns immediately. PreToolUse runs before the question card is drawn. If the hook sat there waiting for your phone, the card would never appear, and you could not answer it from the keyboard either.

The bug that makes "just paste it" unsafe

Claude's modal selectors treat a paste as a choice. Measured on Claude Code 2.1.241, pasting the word hello into an open selector selected the highlighted option, with no Enter. On a plan-approval dialog, that is the agent starting to edit files because you sent a sentence.

So a reply never goes in while that widget is up. The bridge sends Escape, checks that the selector footer is gone, and only then pastes. If the widget is still there, nothing is typed and Discord says so. Refusing is recoverable. Approving a plan by accident is not.

pick is only the digits 1 through 9. The first digit of 12 would already have chosen something.

Try it

You need three things: a paid Claude plan (the free claude.ai tier does not include Claude Code), a Discord bot that only you can DM, and tmux. On Windows the typing half runs inside WSL. Without WSL you can still get the notifications, and you cannot type back into the pane.

On macOS, Linux, or a WSL distro you already have:


bash
curl -fsSL https://gitlab.com/shashankchakraborty712005/agent-bridge/-/raw/main/scripts/get.sh | sh

OrderSift turns messy customer messages into orders you can actually act on.

Shashank Chakraborty — Tue, 13 Oct 2026 08:29:47 +0000

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

What I Built

OrderSift turns messy customer messages into orders you can actually act on.

If you run a small food or craft business, your "order system" is probably your phone. Orders arrive as WhatsApp messages, Instagram DMs, texts, and emails, and every one is written differently. Here's a real-looking one:

Hey Sarah! Can I please get 2 boxes of chocolate fudge cupcakes and 1 red velvet birthday cake with "Happy 30th Dave" written in gold? My nephew has a severe peanut allergy so please make sure completely nut free! We will pick it up on Saturday around 2pm. Call my mobile 555-0199 when ready.

A baker reading that has to pull out the items, the inscription, the pickup time, the phone number, and (most importantly) the allergy. Then they have to notice what isn't there: the customer never said their name. Miss one detail and you've baked the wrong cake, or worse.

You paste the message into OrderSift and get back an editable order card:

Line items with quantities and customizations ("with 'Happy 30th Dave' written in gold").
Pickup date, time, and phone, pulled out of the prose.
Allergy warnings surfaced in special instructions, so they can't hide in the middle of a paragraph.
Prices filled in automatically from the merchant's catalog. "2 boxes of chocolate fudge cupcakes" matches the 6-pack box SKU, not the single cupcake.
A missing-details check that flags what you still need (here, the customer's name) and writes a polite follow-up message you can copy straight back into the chat.
A local order ledger with statuses (draft, confirmed, preparing, ready, delivered) and CSV/JSON export for your spreadsheet or accountant.

Who would pay for it? Home bakers, caterers, custom-apparel sellers, and anyone else taking orders through chat apps. They have too many orders to keep in their head, but they're too small for a POS system or Shopify, and they don't want to make customers fill out a form. The time saved is easy to measure: every order that comes in as a message gets typed up by someone. The cost of a mistake is even easier: one missed allergy note costs more than a year of a small subscription.

Demo

Live app: https://order-sift.vercel.app

Try one of the built-in sample messages (bakery, catering inquiry, custom hoodies) or paste your own. The badge at the top shows which model is serving the request.

Code

Shashank-blip / OrderSift

OrderSift

OrderSift turns messy customer messages into clean, structured orders that a merchant can act on quickly.

Turn chaotic chats into organized, valid orders with AI-powered extraction, local-first processing, and zero cloud leakage.

OrderSift is built for solo businesses, home bakers, caterers, and micro-merchants who receive orders over WhatsApp, Instagram DMs, email, and SMS. Instead of manually copying details from messy conversations, the app extracts useful order data, validates missing fields, and helps send smart follow-up questions back to the customer.

Why this exists

Most small businesses are still handling orders by hand:

reading long chat histories
extracting item details and quantities
reconciling delivery dates and contact info
chasing missing information manually

This creates friction, mistakes, and lost revenue. OrderSift helps simplify that workflow with a local-first, privacy-conscious order intake assistant.

What OrderSift does

Extracts structured order data from messy, real-world messages
Identifies product details, quantities, delivery dates, and customer…

View on GitHub

How I Built It

OrderSift is a Next.js 14 (App Router) + TypeScript app. The AI part is deliberately small and swappable:

1. Open-weight models only. Extraction runs on open-weight models through a provider chain, all on the server:

Groq serving openai/gpt-oss-120b (Apache 2.0) for the hosted demo. Groq is fast enough that parsing feels instant, which matters when you have twenty DMs to get through.
Any OpenAI-compatible endpoint (Together, OpenRouter, a self-hosted vLLM box), configured by environment variable.
Ollama for fully local inference, e.g. qwen2.5 or gpt-oss:20b on the merchant's own laptop. Ollama's format parameter takes a JSON schema, so the model is constrained to valid output.
A rule-based fallback parser so the app still produces a rough draft when no model is reachable. It's clearly labeled as a fallback, because a draft with gaps is more honest than a confident guess.

The app doesn't hard-code which Groq models exist. It asks Groq which models the API key can use and picks the best available one from a preference list. I learned this the hard way: my first deploy kept silently falling back to the rule-based parser because a hard-coded model ID had been retired. Now any fallback shows its reason right in the UI (Heuristic fallback — Groq: HTTP 404 ...), which turned an hour of guessing into a one-line fix.

2. Schema first, model second. The model gets a system prompt with extraction rules and the full JSON schema for an order. A few of those rules came from watching it get things wrong:

A name in a greeting ("Hey Sarah!") is usually the merchant, not the customer. Without this, the model cheerfully assigned the baker's name to the customer.
Keep dates as the customer wrote them. "Saturday" is more useful to a baker than a guessed calendar date.
Keep the unit ("boxes", "dozen") in the item notes, so catalog matching can price a box rather than a single cupcake.

The model's output then goes through a normalizing step (prices or quantities that come back as strings, missing arrays, stray markdown fences) before deterministic code computes totals and missing fields. I don't let the LLM do arithmetic or decide what's "required".

3. Catalog matching for prices and allergens. Customers never use the merchant's product names. A matcher scores each extracted item against the catalog, handling plurals and words like "boxes", and fills in the SKU name, unit price, and allergen list. It only fills items that don't already have a price, so anything the merchant typed is never overwritten. If nothing matches (say, "blueberry muffins"), the item stays unpriced instead of getting a guess.

4. Local-first storage. Saved orders live in the browser's IndexedDB via Dexie. There's no account and no server-side order database by default; the merchant's ledger is on their device and exports to CSV/JSON.

5. Tiger Data as the merchant's back office. The catalog and the cloud ledger live in a Tiger Cloud service (PostgreSQL + TimescaleDB). I built it entirely from my editor through the Tiger MCP server, without opening a dashboard: create the service, apply scripts/setup-tiger.sql, seed products, and inspect rows while debugging. When I realized "2 boxes of cupcakes" was being priced as two single cupcakes, adding the 6-pack SKU was one db_query call. At runtime, the app talks to Tiger directly through pg:

Catalog matching reads merchant_catalog live, so a merchant changes a price in one place and the next parsed order uses it. If the database is unreachable, the app falls back to a built-in catalog and says so in the UI.
"Sync to Tiger Cloud" upserts confirmed orders from the browser into customer_orders_sync, keyed by order number. The local ledger stays the source of truth on the device, and Tiger gives the merchant a copy they can query, back up, or open on a second device.

The catalog table already has a vector(384) column. The next step is filling it with embeddings so matching works on meaning ("fudge buns" → cupcakes), not just keywords.

6. Deployment. One Dockerfile (multi-stage, standalone Next.js output, non-root user) plus a docker-compose.yml that points at Ollama on the host, so a merchant can self-host the whole thing. The public demo runs on Vercel.

Why Does Open Innovation Matter?

For a side-hustle tool, open weights are the business model, not a nice-to-have.

The same model can run anywhere. gpt-oss runs on Groq for the hosted demo, and the same model family runs on a merchant's laptop through Ollama. Switching is an environment variable, not a rewrite. A closed API gives you exactly one place to run it, at that vendor's price.

Privacy is a real choice, not a promise. Order messages are full of personal data: names, phone numbers, home addresses, and health information like allergies. With the hosted demo, that text goes to an inference provider. With the self-hosted Docker + Ollama setup, it never leaves the merchant's machine. I can only offer that second option because the weights are open. With a closed model, "trust us" is the only privacy policy available.

The cost floor is near zero. A baker parsing a couple hundred messages a month shouldn't be paying a per-token bill that grows with their success. Open-weight models on cheap hosted inference (or free local inference) let OrderSift be priced like a small tool, not like a cloud bill.

No single point of failure. When my first hosted model ID disappeared, the fix was to pick another open model from the list. Because multiple providers serve the same open weights, no single provider can deprecate my product out from under me.

Prize Categories

Best Use of Tiger Data

Comparing AI Models in Cursor: Opus 5.5 vs. Grok 4.7

Shashank Chakraborty — Fri, 09 Oct 2026 19:23:21 +0000

Objective

As part of Hacktoberfest, I compared Opus 5.5 and Grok 4.7 in Cursor across three common software development tasks: TypeScript code generation, asynchronous JavaScript debugging, and code explanation.

Methodology

I used the same prompt for both models in each experiment and compared their outputs for correctness, readability, reasoning, edge-case handling, and practical usefulness.

Experiment 1: TypeScript Code Generation

Task: Reverse a string without using the built-in reverse() method, handle empty input, and provide three test cases.

Opus 5.5: Used for...of and prepended each Unicode code point to the result. It also explained the limitation involving multi-code-point emoji.

Grok 4.7: Used a backward index loop and appended characters to the result. The implementation was simple, but UTF-16 indexing can split supplementary Unicode characters.

Observation: Both solutions met the basic requirements, while Opus paid more attention to Unicode behavior.

Experiment 2: Asynchronous JavaScript Debugging

Task: Identify and fix the missing await in a function that fetches users.

Grok 4.7: Correctly identified the unresolved promise and provided a minimal fix.

Opus 5.5: Fixed the same issue, added an HTTP response-status check, and demonstrated caller-side error handling.

Observation: Both models found the main bug. Opus also addressed the fact that fetch() does not automatically reject for HTTP error statuses such as 404 or 500.

Experiment 3: Code Explanation

Task: Explain a chained filter() and map() expression, provide an example, analyze complexity, and identify edge cases.

Grok 4.7: Delivered a focused explanation, correct complexity analysis, and examples of JavaScript type coercion.

Opus 5.5: Provided a more extensive tutorial, intermediate results, and additional cases involving BigInt, sparse arrays, null, and numeric precision.

Observation: Both explanations were correct for the intended numeric-array use case. Opus explored a wider range of edge cases, while Grok was more concise.

Overall Findings

In these three experiments, both models produced useful solutions and explanations. Opus 5.5 consistently explored more edge cases and provided more detailed reasoning, whereas Grok 4.7 tended toward simpler, more direct responses.

This was a small, qualitative experiment rather than a standardized benchmark. The results demonstrate how the choice of model can affect the depth and style of AI-assisted development.

Conclusion

Testing the same prompts across models helped me look beyond the first answer and evaluate correctness, assumptions, and robustness. It also reinforced the importance of running tests and reviewing AI-generated code instead of relying on explanations alone.

Opus 5.5

Grok 4.7

TouchGrass AI: I built an outdoor quest app with Ollama and local-first storage

Shashank Chakraborty — Tue, 06 Oct 2026 21:32:15 +0000

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

TouchGrass AI: turning an AI prompt into a reason to put my phone away

I built TouchGrass AI, a small outdoor quest companion. You choose how much time you have, what kind of outing sounds good, and how much effort you want. It makes a short quest, then the app gets out of the way so you can go do it.

The latest test was on my phone: I generated a quest, took a photo for one of its tasks, and the photo stayed available with the saved quest.

Project: TouchGrass AI on GitHub

What I built

A quest is a handful of simple prompts for a walk, exploring a familiar area, noticing nature, or taking a photo walk. Tasks can ask for photo evidence. If they do, the task stays incomplete until a photo is saved.

The app keeps quests, progress, and photo evidence in the browser on that device. Photos are stored as blobs in IndexedDB, can be previewed or removed, and never go into the service worker cache. The app shell can load offline after it has been visited, and a saved quest can go with you when the signal does not.

How it works

The UI sends the selected activity, duration, and difficulty to a same-origin server route. That route asks Ollama for structured JSON, then validates the response against the quest rules before showing it. If generation is unavailable or the response is not usable, the route returns a ready-made quest instead.

For local development I run Ollama on my computer. For the hosted demo I configured Ollama's API with a Gemma model. The API key stays in the server environment; it is not included in browser code.

The browser stores the quest and its photos locally. In hosted mode, quest-generation settings and the prompt go to Ollama to produce the quest. The app does not ask for or send a location, and the photo evidence is not uploaded.

Why open models matter here

I wanted the AI to help create a personal plan, not become the activity itself. Open models let me keep local inference as a real option, change the model, and inspect the boundary between generation and the rest of the app. The hosted API makes the demo accessible without requiring each visitor to install a model, while the offline part of the experience stays useful after a quest is saved.

That trade-off is deliberate: generation needs a connection in the hosted setup, but the walk, saved tasks, progress, and photo evidence do not depend on a live AI request. A model can suggest the next small thing to notice; it should not need a permanent place in the user's pocket once the walk starts.

What I learned

The most important boundary was deciding what belongs on the server and what belongs on the phone. The server needs only the choices required to generate a quest. The browser owns the saved quest and evidence. Keeping those responsibilities separate made offline use and photo privacy easier to reason about.

I also learned that “works on my laptop” is not the finish line for a camera feature. Testing the deployed app on a phone made the whole loop real: take or choose a photo, save it, see it attached to the task, and continue the quest.

Build session

A lightly edited transcript of the build: practical decisions, one missing persistence bug, and the moment the quests briefly achieved enlightenment by vanishing into tranquility.

TouchGrass: when quests vanished into tranquility

You

okay committed and pushed — lets go to the next phase build

Agent

We moved on to the next phase: keep the quest creation loop useful from first prompt to a saved outing.

You

okay generation too and the fallback both working fine but what happens next when i click go back home the quests vanish into tranquility. vanished. not really being saved though ??

Agent

A peaceful disappearance is charming in poetry and less charming in a quest app. We fixed the home flow so quests are saved locally and show up on the quest shelf after navigation.

You

i noticed the icon in this pg is different keep the leaf one i love it

Agent

The leaf stays. The brand mark was made consistent across the app.

You

okay whats next and make it

Agent

We continued with the next phase, adding photo evidence to tasks that ask for it. Photos are saved on-device in IndexedDB, can be reviewed or removed, and are not cached or uploaded.

You

okay i guess all done so can we move towards deployment?

Agent

We prepared Vercel deployment with server-side Ollama credentials, structured quest validation, and a ready-made fallback if generation fails.

You

for this one i used ollama's api key and then used a model used in ollama for gemma i believe

Agent

We updated the hosted setup to call Ollama's API from the server, so the key stays out of browser code. Gemma can be configured as the hosted model.

You

worked perfectly in my phone too. the photo clciking is perfect

Agent

The mobile test confirmed the camera/photo-picker flow works, and the evidence remains attached to the saved quest on that device. The phone has now passed its field test; the app may politely ask it to go outside.

Try it

Source: github.com/Shashank0701-byte/TouchGrass
The hosted demo is deployed on Vercel. (https://touch-grass-gilt.vercel.app/)

If you'd like to run it locally, clone the repository, install Ollama and the configured model, then follow the README setup steps.

DEV Community: Shashank Chakraborty

Ofrenda is a local altar for long lost repositories which still have unfinished work.

Ofrenda

What I Built

Demo

Code

How I Built It

Why open innovation matters

Prize Categories

Lazyyyyy pardons the notes you were never going to read

What I Built

Demo

Code

Shashank-blip / Lazyyyyy

Lazyyyyy

Why this is local

How I Built It

From GitHub Commits to Tasks: Learning Backend Webhooks Through Open Source

OpenSource #BackendDevelopment #Webhooks #GitHub #WebDevelopment #SoftwareEngineering #BuildInPublic

DocuFlow: Turning Invoice PDFs into Structured Financial Data with Python and Docker

Shashank0701-byte / docuflow

DocuFlow is a containerized, event-driven pipeline that automates ingestion, OCR, parsing, and analytics for invoices and financial documents.

DocuFlow — Intelligent Invoice Ingestion Pipeline

🏗️ Architecture

What does it do?

Under the hood

What I wanted to explore

What's next?

Claude is stuck on a question. Answer it from Discord.

Code

Shashank0701-byte / agent-bridge

Get a Discord DM when your coding agent is blocked, reply from your phone, and have it typed straight back into the session. Works with Claude Code, Codex, or anything with a CLI.

agent-bridge

How it works

What shows up on the phone

Why it types, instead of approving inside the hook

The bug that makes "just paste it" unsafe

Try it

OrderSift turns messy customer messages into orders you can actually act on.

What I Built

Demo

Code

Shashank-blip / OrderSift

OrderSift

Why this exists

What OrderSift does

How I Built It

Why Does Open Innovation Matter?

Prize Categories

Comparing AI Models in Cursor: Opus 5.5 vs. Grok 4.7

TouchGrass AI: I built an outdoor quest app with Ollama and local-first storage

TouchGrass AI: turning an AI prompt into a reason to put my phone away

What I built

How it works

Why open models matter here

What I learned

Build session

Try it

Further reading