DEV Community: Muhammad Mohsin

The Wrong Model for the Job Is Quietly Eating Your AI Budget

Muhammad Mohsin — Wed, 04 Nov 2026 05:54:21 +0000

The Wrong Model for the Job Is Quietly Eating Your AI Budget

Here is a habit almost every AI user has, and almost nobody audits: we open the same model for everything. The flagship model becomes the default tab. Draft an email? Flagship. Summarize a meeting? Flagship. Sort fifty support messages into categories? Flagship — the most expensive model available, doing the simplest job on the list.

Most daily AI work falls into three buckets:

Simple, high-volume jobs. Summarizing, classifying, extracting fields from text, drafting routine replies, reformatting data. The answer is usually obvious once the text is read. These jobs want speed and low cost, not deep reasoning.
Skilled craft jobs. Writing decent code, editing a draft, explaining a concept, planning a workflow. These need a capable general model, but not the biggest one on the menu.
Hard reasoning jobs. Debugging a subtle bug, designing an architecture, working through a genuinely tricky problem with many constraints. This is the only bucket where the flagship model reliably earns its price.

The waste happens when bucket 1 work gets bucket 3 pricing. A classification task that a small model handles in seconds does not get a better answer from a flagship model — it gets the same answer, slower, at many times the cost. And because these simple jobs are usually the high-volume ones, the waste compounds silently: hundreds of small overpayments, every week, that never appear as a single shocking line on the bill.

A worked example (illustrative numbers)

Take a small, realistic routine: a freelancer sorts and drafts replies to 100 customer messages a day, at roughly 500 tokens per message. That is 50,000 tokens a day, or about 1.5 million tokens a month.

Now imagine the flagship model costs, say, 10 times what a capable small model costs per token. The math is then simple and brutal:

On the small model: 1.5 million tokens at the small-model rate.
On the flagship model: the same 1.5 million tokens at 10 times that rate — nine-tenths of the spend buying nothing extra.

These are illustrative rates, not a quote from any provider — actual prices vary and change often. But the shape of the result does not depend on the exact numbers: whenever the price ratio between models is large and the task is simple, defaulting to the biggest model multiplies a routine cost for no return. Run the same arithmetic with your own provider's current prices and your own token counts, and the gap is usually the largest single saving available without changing anything about what you actually produce.

I have seen the same pattern in my own workflow. The moment I started asking "which bucket is this task in?" before choosing a model, the expensive calls dropped sharply — not because I used AI less, but because the hard jobs finally had the budget room they deserved. The flagship model is a better tool when it is used only where it matters.

Four practical fixes

1. Set your default to the smallest model that does the job well. Make the flagship the exception, not the default. If your tool lets you set a default model, change it today; defaults decide more spending than decisions do.

2. Route by task, not by habit. Write down your five most common AI tasks and assign each one a model tier: small, medium, or flagship. Tape that list next to your monitor, literally or figuratively. "Summarize" and "classify" almost never belong in the flagship tier.

3. Escalate on failure, not in advance. Start small. If the output is wrong, unclear, or shallow, escalate that specific task to a bigger model. This one rule alone kills most of the waste: you pay flagship prices only for the tasks that proved they needed them, instead of pre-paying for difficulty that never arrives.

4. Log the model, not just the prompt, for one week. For seven days, note which model handled each task and whether the result was good enough. Most people discover two things: their simple tasks were nearly all fine on the small model, and one or two hard tasks genuinely deserved the flagship.

One warning, in the other direction: do not overcorrect. Routing a genuinely hard reasoning task to a tiny model and then re-running it three times, plus fixing its mistakes by hand, costs more than one good flagship call. The goal is not "always use the cheapest model." The goal is the right model for each job, first time.

The question to take into your next session

Before your next AI task, pause for five seconds and ask: which bucket is this — simple, skilled, or hard? That one question is worth more than any prompt trick I know, because it attacks the bill at the level where the bill is actually decided.

I write about AI costs, billing, and automation that pays for itself, and I build one-time-purchase tools instead of monthly subscriptions. You can find the work at https://onyxailabs.gumroad.com and on YouTube at https://www.youtube.com/@onyxaipk.

What is the simplest task you have been running on the most expensive model — and what happened when you tried it on a smaller one?

I Stopped Renting Software: 12 Tools I Built, Own Forever, and What They'd Cost One by One

Muhammad Mohsin — Tue, 03 Nov 2026 02:38:47 +0000

Every freelancer I know is paying the same quiet tax.

A proposal tool here. A contract tool there. Something for content, something for client messages, something to track what the AI subscriptions themselves are costing. Each one is "only" $15–30 a month — until you add the column up and realise you're renting your own toolbox for over a thousand dollars a year.

I build software for a living, so this year I did the stubborn thing: I built the tools instead, one by one, and I run them on my own machines. No subscriptions. No renewals. My client data never sits on someone else's server.

Here's the full library, honestly priced the way a buyer would price it:

For freelancers & creators

ContractKit ($29) — offline contract studio: 5 templates, signature pads, print-to-PDF. Works with no internet at all.
ProposaLite ($79) — client proposals with built-in e-signature.
PrivateSuite ($39) — AI meeting notes that never leave your laptop. 100% offline.
Viral Content Machine ($49) — a 28-node n8n automation: one topic in, a week of content for 5 platforms out.
AI Spend Tracker ($29) — shows exactly what Claude Code, Cursor and your API keys are really costing you.

For business operations

PrimeERP ($59) — self-hosted mini ERP: CRM, HR, inventory and finance in one dashboard.
TenderOS ($99) — tender & procurement management, end to end.
Digital Product Passport ($79) — product passports with QR verification, built for the EU's incoming rules.
EmoSense B2B ($49) — customer-emotion analytics for support teams.

Automation & AI

WhatsAppKit ($49) — 4 ready-made WhatsApp business automations on n8n.
AgentKit ($59) — 5 local AI agents on n8n that do real work.
AI Content Tools ($19) — a compact AI writing toolkit (runs on your own Gemini key).

Add that column up and it's $638.

So this week I put the whole library into one bundle: the Complete Bundle — all 12 tools for $319, once. Half the one-by-one price, no subscription ever, and every tool ships with complete source files and a step-by-step START-HERE guide.

Two honest notes, because I'd rather say them than have you find them:

It's capped at the first 10 buyers. That's a real launch cap, not a countdown timer trick — when the 10 are gone, the bundle closes.
OnyxIQ, my YouTube growth tool, is NOT in this bundle. It's sold separately. The bundle is the other 12 tools, exactly the list above.

And it carries the same 14-day money-back guarantee as everything in my store: one email, refund, no forms.

If you're a freelancer, an agency, or a solo builder piecing together an AI automation tools pack one purchase at a time — this is the one-purchase version:

👉 https://onyxailabs.gumroad.com/l/complete-bundle

Questions about any of the 12 — what it does, what it doesn't — ask me in the comments. I'd rather answer honestly than sell you the wrong tool.

Dead-Code Ghost: Find Dead JavaScript and TypeScript Functions, Locally, with Gemma 3 1B

Muhammad Mohsin — Sat, 31 Oct 2026 07:10:38 +0000

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

What I Built

Dead-Code Ghost is a free, local, read-only tool that finds dead functions in JavaScript and TypeScript repos — functions that are never called anywhere — and writes a Markdown report about them, with a plain-English note and a last-touched date for each one. It runs entirely on your machine with Gemma 3 1B via Ollama: no cloud, no API key, no subscription.

My interpretation of the theme is literal. A "ghost" in a codebase is a function that was written once and then abandoned — still sitting in the repo, never called by anything. Every real project accumulates them: the helper from a retired feature, the utility left over from a refactor, the exported function nobody imports anymore. They slow down readers, confuse new contributors, and make refactors risky. Ghost finds them so a human can decide what to do. It never deletes or modifies anything itself.

It is built for developers and open-source maintainers cleaning up JavaScript and TypeScript codebases, and it is brand-new code written October 28–31, 2026, for this challenge — not a repackage of anything else I have built.

Repo: https://github.com/onyxailabs/dead-code-ghost

Demo

There is no hosted demo — this is a local command-line tool, so the demo is a real terminal run. Here is the exact output from a scan of the sample repo that ships with the tool, run on a Windows 10 PC:

> npm test
PASS: dead=[deadTsHelper, idle, oldHelper, unusedCalc] exported-unused=[formatDate, publicApi] files=3 functions=9 sample-untouched=true

> node ghost.js scan sample-repo --out dead-code-report.md --no-model
Report written to dead-code-report.md
Files: 3 | Functions: 9 | Dead: 4 | Exported-unused: 2

And the report it writes looks like this (excerpt):

## Dead functions (4) — never referenced anywhere, not exported
- deadTsHelper, idle, oldHelper, unusedCalc
## Exported but never called internally (2) — review, not necessarily dead
- formatDate, publicApi

sample-untouched=true matters: the scan only reads your code. The only file it ever writes is the report you point it at.

To verify the tool computes rather than returning a canned answer, I ran it on a second, completely different folder with different function names — a tiny shop example. It correctly found 4 dead functions (applyOldCoupon, removeFromCart, legacyDiscount, unusedHelper) and 2 exported-but-unused ones (formatPrice, taxRate) out of 10 functions. The same check was then repeated on a Windows 10 PC with the identical result. Same tool, unseen code, correct result.

Code

https://github.com/onyxailabs/dead-code-ghost

Zero-dependency Node.js. Run it with:

node ghost.js scan <your-repo-dir> --out dead-code-report.md --no-model

Drop --no-model once Ollama is running with Gemma 3 1B pulled (ollama pull gemma3:1b) and the report carries a short plain-English note per dead function instead of the skipped-note line. npm test runs the built-in verification suite.

Try it on your own repo and tell me what it found.

How I Built It

The scanner parses .js, .jsx, .ts, and .tsx files and builds a name-based call graph: every function definition is collected, then every other reference to that name across the repo is counted. Comments and strings are stripped first, so a name mentioned only in a comment does not count as a use. Functions with zero references that are not exported are reported as dead; exported functions with zero internal references are listed separately, because code outside the repo might use them.

The open-weight model is at the core of the notes, not bolted on. Gemma 3 1B, running locally through Ollama (http://127.0.0.1:11434), writes a 1–3 sentence plain-English note for each dead function — what it appears to do, without guessing beyond the code. If Ollama or the model is not reachable, the note says so plainly instead of inventing one. That honesty is deliberate: a cleanup tool that invents explanations would be worse than no tool at all.

Last-touched dates come from git log (definition line first, file level as fallback). If the folder is not a git repo, the date is reported as unavailable — never invented.

Honest limits, stated in the report itself: the graph is name-based, not scope-resolved, so two functions sharing a name across files count as one name, and dynamic calls (obj[name](), eval, string-built calls) are not seen. Detection is best-effort, never claimed perfect. The demo transcript above uses --no-model, so what you see is the honest fallback; the Gemma note path is implemented and wired to local Ollama, and its first live run has now happened: on 31 October 2026 the same sample scan was re-run with gemma3:1b pulled and served locally through Ollama — same counts (Files 3 | Functions 9 | Dead 4 | Exported-unused 2), and this time every function carries a real Gemma note. Two examples, verbatim: unusedCalc — "This JavaScript/TypeScript function takes a number as input and returns its square." formatDate — "This function formats a date string into a human-readable format, likely displaying the date and time in a standard way." One honest operational note: on a cold model the first calls can hit the tool's 30-second timeout and fall back to the unavailable line; with the model warm, all six notes came back real.

It runs on Windows 10/11 with Node.js and Ollama, no GPU, on an 8 GB machine — the 1B model class is the whole point.

Why Does Open Innovation Matter?

Three things a closed API could not give this tool at the same time:

It works with the internet off. The scan, the model, and the report are all local. A developer on a slow or metered connection — or on a plane — can still clean up a repo.
Your code never leaves your machine. A cleanup tool reads your entire codebase. Sending that to a cloud API means trusting a third party with proprietary code. Here, nothing leaves the machine except the report you choose to share.
It cannot disappear or start charging. No API key, no subscription, no service that might shut down or change its pricing. An open-weight 1B model that fits on an 8 GB laptop makes the whole thing free forever.

Open innovation is what makes a privacy-sensitive, offline, zero-cost tool possible at all — not just cheaper, but possible in a form a closed service cannot match.

Prize Categories

Best Use of Gemma (featured category): Gemma 3 1B via local Ollama writes the plain-English notes that turn a list of function names into a report a human can actually act on. The model is not decoration — it is how the report becomes readable.

How to Check If ChatGPT Can See Your Website: A Free AI Visibility Check (With My Real Results)

Muhammad Mohsin — Sat, 31 Oct 2026 06:38:36 +0000

How to Check If ChatGPT Can See Your Website

Last week, people started asking AI assistants about products instead of Googling them. You already know this. What I didn't know — until I checked — is what those assistants actually say about my business.

So I ran a free AI visibility check on my own website. The short version: 100 out of 100 AI answers about my business described a completely different company. Wrong founder. Wrong country. Wrong products. Zero answers mentioned me.

This post is the full check, step by step, with my real results as the worked example — including the parts that were my own fault, and the fixes I'm making first. You can run the same check on your site, free, in a few minutes.

What "AI visibility" actually means

When someone asks ChatGPT or Google's AI Overviews "what is [your business]?", the assistant builds its answer from pages it can read and trust. Roughly, it depends on three things:

Can it read your site at all? Plain, crawlable text. If your key facts only exist inside images, scripts, or vague marketing copy, the machine sees very little.
Is your site's structure clear? Headings, descriptive pages, and structured data (like an Organization schema block) tell a machine what kind of thing you are without guessing.
Do other pages agree with you? Assistants lean on sources across the web. If third-party pages define you differently — or define someone else with your name — the assistant follows the louder, clearer signal.

That third point is where my site fell apart.

The free check, step by step

The tool I used is the Wellows AI Visibility Report (free, launched this week — no account, no card). Here's the exact process:

Open the tool and enter your domain, an email (the report link is sent there), and your country. I entered my own site, onyxailabs.me, with United States as the country.
Wait for the audit. The page promises about four minutes; mine took just over six. Behind the scenes, it asks four AI assistants — ChatGPT, Google AI Overviews, Gemini, and Google AI Mode — the same question, five times each, in fresh sessions, and saves every answer and every source.
Read the headline result first. Mine: 100 of 100 people who ask about Onyx AI Labs are told about something else. Google AI Overviews described something else every time. Gemini did too — it was reading the other company's facts page as its source. ChatGPT sometimes went further and warned people about my brand.
Check what the answers actually say. Two in three answers mentioned a headquarters or country — and named Canada, not Pakistan. The founder they named was C. Michael Gibbs — not me. Every answer described an enterprise AI company or an open-source search platform. None mentioned my actual products, my prices, my free tier, or my money-back guarantee. The report listed thirteen things my site says about the business; the assistants repeated none of them.
Check the sources. This was the number that explained everything: 0% of the assistants' sources were pages I own. For all four assistants. Instead, one domain — onyxailabs.com, a different company, an enterprise AI lab in Toronto that owns the .com version of my name — held 75 of the 115 sources used. The assistants read the .com nine times out of ten and never opened my .me site at all. In sixteen answers, the very first source read was that company's homepage — and once an assistant reads the wrong page first, it builds the whole answer from it.

Why it happened (the report's three causes, in order)

My name belongs to someone else online. The .com company has more pages, more links, and the conventional domain, so every assistant treats it as the real answer to the name.
First sources win. If the first page an assistant reads defines the name wrong, the rest of the answer follows it.
Mixed signals on my own site — this one is on me. The sentence that defines my business was on my homepage, but not at the top. And my structured Organization data was missing five of nine fields: description, founding date, address, rating, and contact.

That third point stung, because a day earlier I'd had to add a clearer "what this product does" section to the same homepage for an unrelated app verification — a human reviewer needed the same thing the AI did: tell me plainly what this is, at the top, in one sentence. Machines aren't confused by different things than people are. They're confused by exactly the same things.

What to fix first

From the audit and the fix plan it generated, ranked cheapest first — this is my actual to-do list, and most of it applies to any small site:

Open your homepage with a definition. Not a slogan — a sentence. The report handed me mine: "Onyx AI Labs is an independent one-person studio run by Muhammad Mohsin in Pakistan." It goes in the first paragraph, above any sales claim, and into the meta description and title.
Complete your structured Organization data. Fill the boring fields — description, founding date, address, contact. Mine was missing five of nine, which means the one machine-readable summary of my business was mostly blank.
Say one consistent thing everywhere. One clear price message ("pricing starts at $49"), the same founder name, the same location — on every page. Contradictions and vagueness are what let a louder namesake win.
Add one worked example. Who used your product, for what, and what happened. Assistants quote concrete stories; they can't quote your feature list into a reputation.
Get independent pages to define you the same way. A LinkedIn company page, a directory listing, a profile — three pages that aren't yours, all saying the same sentence about you. Then re-run the same question later and measure whether the answer changed.

The honest limits

A free report is a snapshot, not a ranking. Mine was one question, asked five times per assistant, on one day — AI answers vary, and one round proves very little. The free audit also allows one check per brand and country every thirty days; ongoing tracking is the paid product. And no report fixes anything by itself — it hands you the list. The fixing is still yours.

You don't even need the tool. The manual version from Wellows' own guide: write down the real questions your buyers ask, ask them in a private browser window, and log three things in a spreadsheet — were you mentioned, was your website quoted, and what did the answer reveal about you? Repeat weekly.

My own plan is exactly that: do the week-one fixes, then re-run this same audit in twelve weeks and publish whether the answer changed. Whatever it shows.

I build small AI tools and free utilities at onyxailabs.me — the PDF tools there are free, and OnyxIQ Basic, a YouTube growth tool, is free on Gumroad if that's your world.

Run the check on your own site before your next customer asks AI about you. Then tell me honestly in the comments: did it describe your business — or someone else's?

Automation That Actually Saves Money — And the 3 Tests That Kill the Rest

Muhammad Mohsin — Wed, 28 Oct 2026 05:53:17 +0000

Automation That Actually Saves Money — And the 3 Tests That Kill the Rest

Every automation demo looks like it saves money. A workflow runs, a screen fills itself in, and the audience nods. Then the bill arrives — a subscription for the automation tool, a subscription for the AI model inside it, a server fee, and a maintenance afternoon nobody put on the slide.

I build automations for a living, mostly with n8n, and I have killed more of my own workflows than I have shipped. The survivors all pass three tests; the failures always failed at least one. Run your next idea through these before you build it — you will save more money by not building the wrong thing than by building anything at all.

Test 1: Does it replace recurring spend, or just recurring effort?

There are two kinds of savings, and only one shows up in your bank account. Replacing effort feels good; replacing spend is what pays. A workflow saving twenty minutes a week is worth building only if those minutes were going to cost you something — a freelancer's hour, a missed order, a late fee. If the task was free but boring, the automation itself has to be nearly free, or you have traded boredom for a bill.

A concrete example: a small shop owner asked me why a WhatsApp bot should cost $50 a month. His shop mostly needed one thing — take orders and answer the same ten questions (prices, delivery areas, opening hours) on WhatsApp. A vendor plan at $50 a month is $600 a year, charged whether he sells anything or not. The version I built for him runs on n8n, self-hosted, using Meta's official WhatsApp Cloud API — no vendor markup, no monthly bot fee. The remaining costs are his own: a small server and Meta's own messaging pricing, both of which he controls.

Before you automate anything, write down the recurring number it removes. If you cannot name one, the automation is a hobby, not a saving.

Test 2: Count the hours honestly — including maintenance

This is where most automation math quietly lies: people count the hours saved and forget the hours spent. A realistic ledger is 3–6 hours to build something genuinely useful, at least an hour a month fixing it (the API changes, the site redesigns, the model updates and your prompt stops working the same way), plus someone noticing when it breaks. A workflow that fails silently for two weeks has not saved anything — it has hidden a problem.

Do the arithmetic over a year. A workflow saving 30 minutes a week saves 26 hours a year; if it costs 5 hours to build and 12 hours a year to maintain, you net 9 hours. If it saves 30 minutes a month, you lose. I have seen workflows that "saved" an hour a month and cost an afternoon every quarter to repair, kept only because deleting your own work feels like admitting defeat. Delete it anyway.

Give every workflow a 90-day review date and the one number that decides whether it lives — without that, it quietly becomes another subscription you forgot you owned.

Test 3: Does it run on infrastructure you control?

An automation built on a vendor's platform, calling a vendor's AI, storing data on a vendor's server, has three separate price levers pointed at it — and you control none of them. The platform can raise its price, change its plan limits, or shut down a feature your workflow depends on, and the rebuild always costs more than the original build.

The alternative is not "never use a service." It is: keep the moving parts on infrastructure you can move — self-hosted n8n on your own server, data in your own spreadsheet or database, AI calls through an API key you can swap between providers. If one provider doubles its price, you change a credential, not rebuild a business. That is also why I track my own AI coding spend: you cannot negotiate a bill you cannot see. When I first measured my own usage, the leaks were mundane — idle sessions re-reading expired context, subagents carrying full context for small jobs, a flagship model doing cheaper work (I covered these in an earlier article). Measurement comes before automation, because automating a wasteful process just produces waste faster.

The automations that pass all three

Three kinds of automation almost always pass:

1. The same ten questions, answered the same way. FAQs, order-taking, appointment confirmations. High volume, low variation — a shop owner answering "what time do you close?" forty times a day is not doing anything else in those minutes.

2. The content pipeline with a queue, not a dump. One idea turned into a week's posts replaces the ten hours after the idea — hooks, drafts, platform versions, scheduling — with one supervised run, published every few hours instead of all at once. The key word is supervised: a fully unsupervised content machine eventually publishes something you have to apologise for, and apologies are expensive.

3. The bill you can finally see. Spend tracking, usage alerts, a weekly summary of what your tools actually cost per project. It does not feel like automation, but it makes every other decision cheaper — including the decision to cancel something.

Notice what is missing: automations that replace judgement. Approving a refund, answering an angry customer, deciding whether a lead is worth a call — every time I have seen those fully automated, the saving was real and the damage was bigger. Automate the repetitive middle; keep a human at both ends.

What is one automation you built that quietly cost more than it saved — and when did you realise it? The best automation lessons I have learned all came from other people's deleted workflows.

I build one-time-purchase automation tools and write about AI costs and YouTube growth — you can find the tools at https://onyxailabs.gumroad.com and the channel at https://www.youtube.com/@onyxaipk.

I Tested GPT-6's Intelligent UI by Building 3 Real Tools (Free Methods Inside)

Muhammad Mohsin — Mon, 26 Oct 2026 14:00:39 +0000

Watch the video here: https://www.youtube.com/watch?v=nK0dfocgf9k

I just published a new video testing OpenAI's GPT-6 Intelligent UI in a practical way: instead of talking about features in the abstract, I built three working tools inside ChatGPT and checked whether the results were actually usable.

The idea behind Intelligent UI is simple. You describe what you want, and ChatGPT builds an interactive interface for it, rather than giving you only text. That sounds useful, but it only matters if the tools work with real inputs and correct results. So I tested it with everyday examples.

The first tool was a Bill Splitter. I entered a bill of Rs 4,500 and added a 10% tip. The tool calculated Rs 450 in tip, a total of Rs 4,950, and Rs 2,475 each for two people. That is the kind of small calculation that is easy to get wrong in a hurry, so I checked the numbers rather than accepting them at face value.

The second tool was a Budget Calculator. With Rs 4,000 in income and Rs 2,200 in spending, it showed Rs 1,800 left. Again, the value is not in a fancy layout. It is in getting a clear answer from a simple input, without needing a separate app or spreadsheet.

The third tool was different: a small school game built inside ChatGPT itself. It shows that this approach is not limited to calculators. The same workflow can produce something interactive that students can use directly, without installing anything extra.

I should be honest about one limitation. The ChatGPT Playground route was blocked for me because of sign-in requirements, a US-adults-only restriction, and limited tokens. The video therefore shows the in-ChatGPT path, which is the route that worked and that most readers can try without running into the same block.

If you want to try these yourself, the exact prompts for all three tools are in the video description. You can copy them, change the numbers, and see how the tools respond to your own inputs.

Watch the video here: https://www.youtube.com/watch?v=nK0dfocgf9k

Onyx AI Labs / OnyxIQ is a project from this channel, and you can find it here: https://onyxailabs.gumroad.com

6 Days Late to My Landlord: I Built "Kal Karo" ('Do It Tomorrow') — a Local AI That Does the Dreaded Task For You

Muhammad Mohsin — Fri, 23 Oct 2026 15:40:46 +0000

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

What I Built

In Urdu and Hindi, when you want a task to go away, you say "kal karo" — do it tomorrow. I say it a lot. To the landlord's email (six days old). To my Downloads folder (an archaeological site). To the meeting notes where somebody agreed to do something and nobody remembers who.

Every productivity tool I have tried responds to this by giving me more work: a better list, a smarter dashboard, a notification that says the quiet part louder. So for this challenge I built the opposite. KalKaro takes the dreaded list and does it — the boring 90% of it, today, on your own machine.

You write your tasks in plain words, one per line:

Reply to my landlord Mr. Rashid about the kitchen tap that has been leaking — his email came 6 days ago...
Sort out my Downloads folder at last — it is a mess of receipts, scans, screenshots and random files...
Make sense of my meeting notes from Tuesday's team call...

A local open-weight model breaks each task into micro-steps and labels every one DOABLE-BY-MACHINE or NEEDS-HUMAN (with the tiniest possible first action). Then KalKaro executes the machine steps itself, with three skills:

Drafter — writes the actual reply you have been avoiding, ready to copy, paste and send.
Organizer — classifies, renames and sorts a messy folder into Category/YYYY-MM/ with clean names.
Digester — turns rambling notes into a summary, the decisions, and who-owes-what action items.

Everything lands in one done-for-you report: what was finished, the drafts themselves, the digests, measured timings — and for whatever is left, one tiny human step per task. KalKaro never sends, posts or deletes anything. Pressing send stays gloriously human, takes about four seconds, and is rather the point. The whole thing runs 100% locally on Llama 3.2 1B via Ollama: no cloud, no API key, no subscription, and your most embarrassing overdue tasks never leave your disk.

Results at a glance (from the real demo run below): 3 dreaded tasks finished · 5 of 5 files filed · 1 reply drafted · 1 set of notes digested · 0 failures · about 13 measured minutes of machine time on a contended 2-core VM — against roughly 30 minutes by hand for the notes task alone. The full payoff table, quality flaws included, is at the end.

Demo

No deployed link and no "coming soon" — KalKaro is a local tool, so the demo is a real run you can inspect and reproduce. The repo's demo/ folder holds the dreaded list, the messy folder and the messy notes; run-demo.sh executes the whole pipeline on a copy and saves the unedited transcript to demo/DEMO-OUTPUT.txt. Here is that run, condensed only by removing repetition:

▸ Task 1: Reply to my landlord Mr. Rashid about the kitchen tap…
  ⛨ guardrail: added the Drafter step the planner missed
  ✓ draft written → drafts/draft-1.md
  done in 3m 8s

▸ Task 2: Sort out my Downloads folder at last…
  ⛨ planner failed (model call timed out after 150s (wall-clock limit)) — deterministic fallback plan: organizer only
  ✓ organiser: 5 file(s) moved
  done in 4m 49s

▸ Task 3: Make sense of my meeting notes from Tuesday's team call…
  ⛨ guardrail: dropped a Drafter step — a notes task needs a digest, not a message
  ✓ notes digested → digests/digest-1.md
  done in 5m 17s

The draft it wrote for the six-days-late landlord email:

Hello Mr. Rashid,

I wanted to follow up on my email from six days ago regarding the kitchen tap that has been leaking. I've been meaning to address this issue, but I've been putting it off. I'm now at a point where I need to apologize for the delay and ask for your assistance in sending a plumber to fix the problem this week. I would greatly appreciate it if you could provide a specific time for the plumber to arrive. I've been keeping track of the time, and I'm expecting the plumber to arrive sometime this week. I'm hoping this will be resolved soon, and I'm grateful for your understanding in this matter. I'm looking forward to hearing back from you and finding a solution to this issue. Thank you for your time and assistance.

Best regards

Not perfect — it muddles who emailed whom (it "follows up on my email", when Mr. Rashid's email is the one being answered) and breezily announces "I'm expecting the plumber to arrive sometime this week", which is the landlord's call to make, not the tenant's. But the apology is in there, the ask is in there, and it is sendable after a 30-second tidy. That tidy is the remaining human step, and the report leaves it to you under its first move: "Compose email."

The folder, before → after:

Before	After
`IMG_4021.png`	`Media/2026-10/img-4021.png` (filed by filename — the model can't see photos)
`expense-export-sept.csv`	`Document/2026-10/expense-export-sept.csv` (classified from its own content)
`fix-login-bug.js`	`Code/2026-10/fix-login-bug.js` (by extension — no model call at all)
`receipt-coffee-shop.jpg`	`Receipt/2026-10/receipt-coffee-shop.jpg` (by filename)
`scan_003.pdf`	`Invoice/2026-10/scan-003.pdf` (recognised as an invoice from its own text — but it kept its scanner name this run)

Five files, five filed in the right category — and note how the folder task got there: its planner call timed out, so a deterministic fallback plan (organizer only, no planner involved) did the filing. The notes digest is the honest weak spot of this run. The summary carries the big calls (landing page v2; discount until Oct 31) — and then repeats them, near-verbatim, in a second paragraph. The Decisions section itself came back empty. The nine action-item lines cover what is really four jobs: Sara's banner sizes twice, Dev's invoice chase four times under two different owners, the blog read-through given to the wrong person, two lines that invent owners for jobs the notes left unassigned — and Dev's image-compression job, the most concrete task in the notes, missing entirely. All of it, including the flaws, is in the transcript.

One more digest test, because the demo's notes are kind compared to real ones. I keep a nastier fixture: client call notes where the annual discount is explicitly left open — "annual discount could be 10% or 15%. Nadia will decide after finance reviews it. Nobody agreed a final discount on this call." An earlier build of the Digester filed that line under Decisions, stated as calmly as the settled items. That is the one sin a notes tool must never commit: presenting an undecided thing as decided is worse than missing it entirely, because somebody will act on it. So the fix is not a sterner prompt — it is a deterministic pass in code. Any extracted "decision" carrying an unresolved marker or an either/or figure is split out into an Open questions section, and the summary is checked for sentences that contradict the split. After the fix I re-ran that fixture three times end-to-end (between half a minute and just over two minutes a run): the discount never appeared as a decision again. Once the summary itself flagged it as unresolved; once it surfaced as what it actually is — an action item, "Nadia — decide on annual discount." The fixture ships in the repo as demo/notes-hard.txt (its task line is demo/tasks-hard.txt) and the three re-runs are written up in QA-RERUN-REPORT.md — the claim is checkable, not asserted. A 1B model will keep trying to tidy open questions into answers. A rule can simply refuse to let it.

Code

onyxailabs / kalkaro

KalKaro — a local AI agent that does the dreaded task for you (files, notes, drafts). Runs on your own machine with Ollama.

KalKaro

"Kal karo" is Urdu/Hindi for "do it tomorrow." It is also, not coincidentally, what I have been saying to the same three tasks for about a week.

KalKaro is a small local AI agent that takes the list of tasks you keep postponing, breaks each one into micro-steps, and then does the machine-doable 90% itself — today, on your own machine. What it leaves you is the tiny human step at the end: press send, glance at a summary, pick a morning.

It runs 100% locally on an open-weight model (Llama 3.2 1B via Ollama). No cloud, no API key, no subscription — and your dreaded tasks, including the embarrassing overdue ones, never leave your disk.

What it does

Give KalKaro a plain-words list of dreaded tasks:

Reply to my landlord Mr. Rashid about the kitchen tap that has been leaking — his email came 6 days ago
Sort

…

View on GitHub

Plain Node (18+), zero dependencies beyond Ollama itself. The interesting files: kalkaro.mjs (planner, executor, routing guardrails, report writer), skills/drafter.mjs (refusal detection + voice), skills/organizer.mjs (few-shot classification + date grounding), skills/digester.mjs (decomposed extraction), and demo/DEMO-OUTPUT.txt (the proof). The full build log — every failure included — is BUILD-REPORT.md in the repo root.

How I Built It

Around the model, honestly. KalKaro's intelligence is Llama 3.2 1B Instruct (q4_K_M, ~800 MB) served by Ollama on localhost. I chose a 1B model on purpose: it runs on any laptop CPU, costs nothing, and keeps private tasks private. Then I spent the week learning what a 1B model actually needs around it — because the first versions were a mess, and each fix taught me something real:

Stream everything. My first end-to-end run died at exactly 5m 02s with fetch failed — with non-streaming calls, Ollama sends nothing until generation completes, and Node's fetch gives up at 300s. The model was fine; the plumbing wasn't.
The grammar shapes JSON, not its length. Ollama's structured output gave me valid JSON — pretty-printed across 111 lines until it hit the token cap mid-string. Fix: demand single-line output, cap generation, and make the parse-retry ask for a much shorter plan instead of repeating the request that overflowed.
Small models refuse and drift. Llama 1B declined to draft a landlord email ("I can't fulfill this request", and once, memorably, that the message "could be used to deceive or mislead"). It also writes in the third person about you, and invents dates. Fixes: concrete first-person prompts with a small example of the voice, a refusal detector with a plain-language retry, and a rule that a date in a new filename must literally exist in the source file or it gets stripped.
Decompose, then guardrail. One prompt asking for summary + decisions + action items reliably produced two sections and stopped — always dropping the action items. So the Digester makes focused calls per section and assembles the brief in code. And around the planner sit deterministic routing guardrails grounded in your own words: a task that never mentions a folder does not get an Organizer step; a notes task does not get a draft; code files file themselves by extension. Every guardrail prints a ⛨ line in the transcript when it fires. The model proposes; the rules dispose; you can watch both.

Development happened on a shared 2-core VM that also renders my videos, which is why the demo's timings swing wildly. The run transcribed above took about 13 minutes wall-clock on a box whose load average spiked past 8 — heavy enough to time the folder task's planner out at 150s, which is why you can watch the fallback plan fire in the transcript. A day earlier, the identical demo on the same contended machine took 41 minutes; a single notes task on a warm, quieter machine today finished in 29 seconds. I left the timings in as measured rather than tidying them; on your own laptop, budget minutes — a 1B model is a tortoise, albeit a reliable one.

Why Does Open Innovation Matter?

Because the tasks on a dreaded list are exactly the data you least want in someone else's cloud. "I owe my landlord an apology and my rent conversation is six days stale" is not a prompt I want on a usage dashboard, metered by the token. An open-weight model on my own machine makes KalKaro possible at all: zero cost (a tool for postponers cannot itself be a subscription you postpone cancelling), total privacy by architecture rather than by policy, and — just as important — inspectable. Every trick in the How I Built It section exists because I could watch my own model's raw behaviour, retry it, re-prompt it and wrap rules around it without asking anyone's permission or paying for the privilege of debugging. Open weights turned "AI assistant" from a service I rent into a part I can build with. A part, notably, that works offline, on a train, on a laptop from 2019, in Muzaffargarh or anywhere else the cloud is far away.

My Agent Session

I built KalKaro with an AI coding agent as a pair, in this workspace, across one long day — and the session nearly didn't survive it: the development VM restarted often enough to kill four builder attempts mid-work (once mid-demo, wiping the temp folder). The countermeasure was unglamorous and total: a BUILD-REPORT.md checkpoint updated after every verified step, so any restart lost minutes, never the thread. That log ships in the repo, timestamps, failed runs and all. I don't have a DevRelay embed to offer — the build log is the session record, and I'd rather show you the real artefact than a polished replay.

The Lazy Payoff

Real numbers, from the demo run above (KalKaro's own report, unedited; timings measured on the contended dev VM — see the note in How I Built It):

Dreaded task	Days postponed	By hand (planner's estimate)	KalKaro (measured)	Your remaining step
Reply to landlord about the leaking tap	6	no estimate	3m 8s	Compose email
Sort out the Downloads folder	—	no estimate	4m 49s	Open the folder and eyeball the new layout
Make sense of Tuesday's meeting notes	7*	~30 min	5m 17s	Open the digest and star your action items

*The planner's guesses are rough — it read "sitting there all week" as 7 days. The 6 days it got exactly right, because the task text said so and KalKaro takes the number from your own words when the planner drops it.

And the honest failure count, because a payoff table without one is marketing: in the two plans the planner returned it proposed 9 steps; 3 machine steps executed, none were marked prepared-only, and the routing guardrails had to correct the plan in 2 of 3 tasks — adding the Drafter step the planner forgot on the landlord task, and removing the one it invented for the notes. The third plan never arrived (150s timeout), and its task finished anyway on the fallback. The draft needed a human tidy (the who-emailed-whom muddle above). The digest was the run's weakest output, as detailed in the Demo section: a right-but-repetitive summary, an empty Decisions section, and nine noisy action lines for four real jobs. Zero tasks failed — but "did not fail" and "did it well" are different claims, and for the notes this run only earns the first. What KalKaro actually saved was not the minutes in the middle column — it was the activation energy. The reply existed. The folder was filed. The notes had a summary and names next to actions, two of them wrong. Each task went from "anxiety with no shape" to "one small step with a first move attached", and that, if you are the kind of person who says kal karo, is the whole game.

Slow and steady, indeed: the tortoise here is a 1B model on a laptop CPU, and it still finished the list before tomorrow.

I Built 50 PDF Tools That Never Upload Your Files — Here's How They Run Entirely in the Browser

Muhammad Mohsin — Fri, 23 Oct 2026 13:00:56 +0000

Think about the last time you used a "free PDF tools" site.

You needed to merge two PDFs, compress a scan, or sign a contract. So you dragged your file into the browser and watched a progress bar while a copy of that document — a contract, a bank statement, a scan of your ID — was uploaded to a server owned by people you have never met.

Does the site delete it afterwards? Maybe. There is no way for you to verify it. The privacy policy says "we take your privacy seriously," which is easy to write and impossible to audit.

Here's the part that bothered me enough to start a project: the upload was never actually necessary. It's a habit the industry formed when browsers were weak. Modern browsers ship with WebAssembly, Web Workers, and more than enough CPU power to do this work locally. A PDF doesn't need to travel to a datacenter to be merged, split, encrypted, or OCR'd — it can be processed in the same tab where it already lives.

So I built OnyxPDF: 50 PDF and image tools that run entirely in the browser.

What was built

OnyxPDF is a set of 50 tools — 32 PDF tools and 18 image tools — that run 100% client-side. No server processing, no uploads, no account, and no cost.

The simple tools are the ones you'd expect: rotate, reorder pages, extract pages, resize and convert images. The interesting engineering was in the hard ones:

Merge, split, compress, and convert PDFs without the file ever leaving the tab
OCR in 7 languages, turning scanned pages into searchable, selectable text
True redaction — actually removing the underlying text and image data, not just drawing a black rectangle over it that anyone can peel back
Signing documents directly in the browser
Real AES-256 encryption, the strongest encryption the PDF format supports, applied locally
AI background removal for images, using a segmentation model that runs on-device instead of a remote API

How it works

PDF parsing and manipulation in a Web Worker

PDFs are parsed, manipulated, and rebuilt entirely with JavaScript and WebAssembly. All of that heavy work runs inside a Web Worker, so the main thread stays responsive and the UI never freezes — progress bars keep animating even while a long document is being rebuilt page by page.

The shape of it looks like this:

// Main thread: hand the bytes off, stay responsive
const worker = new Worker("pdf-worker.js");
worker.postMessage({ type: "merge", files: [bufA, bufB] });
worker.onmessage = (e) => saveResult(e.data.output);

// pdf-worker.js: the heavy lifting happens off the UI thread
self.onmessage = async (e) => {
  const output = await mergeDocuments(e.data.files);
  self.postMessage({ output });
};

OCR via a WebAssembly build of Tesseract

OCR is the feature people most assume "needs" a server. It doesn't. Tesseract, the open-source OCR engine, has a build that compiles to WebAssembly, so the same engine that powers server-side OCR pipelines can run inside a browser tab. OnyxPDF uses it to recognize text in 7 languages, entirely on your machine.

Encryption, implemented client-side

AES-256 isn't something you bolt onto a PDF afterwards — it's part of the PDF format itself, and it's the strongest variant the spec defines. Because the format supports it natively, the encryption can be applied completely on the client. Your password never gets transmitted, and neither does the document. Which is good, because "upload your confidential file so we can encrypt it for you" is a sentence that should make everyone pause.

Background removal with an on-device model

Most background-removal tools are a thin frontend over someone else's hosted API: your photo gets uploaded, processed remotely, and billed by the call. OnyxPDF instead ships a segmentation model that runs on-device, in the browser. Your photos stay on your machine, and there is no per-image API cost hiding anywhere.

The gotcha: large files and browser memory limits

The hardest problem wasn't any single tool. It was memory.

A server can throw RAM at a problem. A browser tab can't — it lives under strict heap limits, and those limits are tighter on mobile devices. A PDF that looks harmless on disk can balloon in memory once you start decoding it. Render a long scan at high resolution and suddenly you're holding hundreds of megabytes of raw page bitmaps at once.

What made it workable:

Chunking — process page by page instead of loading the whole decoded document into memory: handle a page, release it, move on
Workers everywhere it matters — long tasks and their garbage stay off the main thread
Releasing decoded pages aggressively as soon as a page is finished, instead of letting bitmaps accumulate
Streaming results out where possible, rather than building one giant in-memory structure

None of this is exotic. It's just the discipline of treating the browser as the resource-constrained environment it actually is — the same discipline server-side tools never had to learn, because the server could always be given more RAM.

The proof anyone can run

You don't have to take any of this on faith, because the architecture makes it verifiable in about thirty seconds:

Open OnyxPDF and let the page load.
Switch your device to airplane mode.
Pick any tool and process a file.

Everything still works — because there is no server to disconnect from.

Prefer a second test? Open your browser's Network tab while converting a file and watch the requests. Beyond loading the page itself, nothing uploads your document. Zero file uploads, because there is nowhere for them to go.

Try it

OnyxPDF is free, needs no account, and lives here:

👉 https://onyxailabs.github.io/onyxpdf/

It's built by Onyx AI Labs, and it's actively maintained. Feedback is genuinely wanted — if there's a tool you wish existed, or you hit a bug, I want to hear about it.

I'll close with the question that started this whole project:

Which PDF tool do you still have to upload files to a random site for?

How I Automated WhatsApp Orders for a Small Business with n8n (Full Workflow Breakdown)

Muhammad Mohsin — Fri, 23 Oct 2026 07:55:40 +0000

If you run a small business, your "storefront" probably isn't a website. It's a WhatsApp number.

And your "checkout flow" is a stream of chat messages like this:

"Hi, is the blue one available?"
"2 chicken burgers and a fries, deliver to Green Town"
"How much total?"

Every one of those messages needs a human to read it, figure out what the customer actually wants, reply, and write the order down somewhere before it gets buried under newer chats. On a slow day, that's fine. On a busy day, messages get missed, orders get mixed up, and sales are lost simply because nobody could type fast enough.

So I built an automation for it in n8n. This post is the full breakdown: what the workflow does, why each step exists, and the gotchas to avoid if you build your own.

The problem: one chat, four separate headaches

WhatsApp ordering looks simple from the outside — "just take the order." In practice, four different jobs land in the same chat window:

Order capture. Someone has to turn a free-form message ("send 2 of the chicken one and one zinger") into a structured order: item, quantity, name, delivery address.
Lead qualification. Not every message is an order. Some people are price-shopping, some want a bulk quote, some are just browsing. They shouldn't all get the same treatment.
FAQs. "What time do you close?" "Do you deliver to my area?" "Is cash on delivery available?" The same handful of questions, answered again and again, every single day.
Follow-ups. The customer who asked about a price three hours ago and went quiet. Without a nudge, that conversation just dies.

A good automation has to handle all four — which is why "just connect WhatsApp to a chatbot" usually disappoints. The trick is to route first, automate second.

The workflow, step by step

Here's the architecture I ended up with. It's a single n8n workflow with a clear path:

WhatsApp message → Webhook trigger → Parser → Intent router → branch (sheet + confirmation reply) → Human handoff for everything else

Step 1: The trigger (webhook)

The workflow starts with a Webhook node. When a customer sends a WhatsApp message, the WhatsApp Business API (or a provider built on it) POSTs the message to that webhook URL, and n8n wakes up with the sender's number and the message text in the payload.

Why a webhook: it's event-driven. You don't poll anything, you don't burn executions while idle, and the customer gets a reply in seconds instead of whenever someone notices the phone buzzing.

Step 2: The parser

Raw chat text is useless to a database, so the next step extracts structure from it: which items were mentioned, what quantities, a name if the customer gave one, and the delivery address if present. A simple approach is keyword matching against your menu or product list. A more flexible one is sending the message to an LLM with a strict JSON output schema (item, quantity, name, address) and validating the result before anything downstream touches it.

Why this step exists on its own: parsing fails sometimes ("the usual pls"). If parsing is a separate step, you can inspect exactly what it extracted, log the failures, and improve it without touching the rest of the workflow.

Step 3: The intent router

This is the heart of the design. A Switch node classifies each message into one of three intents:

Order — the customer wants to buy something.
Question — they're asking about hours, delivery areas, payment methods.
Lead — bulk orders, catering, resale, anything that deserves a real conversation and a follow-up.

Why route before acting: each intent needs different handling, different data, and a different tone. An order needs accuracy. A question needs speed. A lead eventually needs a human — but a logged human conversation, not one buried in a chat list.

Step 4: Log the order (Google Sheets or Airtable)

Order-branch messages get written as a row in Google Sheets (or Airtable, if you want nicer views): timestamp, customer number, name, items, quantities, address, status = "New". The team works from the sheet, moving the status from "Preparing" to "Delivered".

Why a spreadsheet and not something fancier: the business owner already knows Sheets. Zero training, zero new logins. The fanciest system in the world loses to the one people actually open.

Step 5: The automatic confirmation reply

Immediately after logging, n8n sends a WhatsApp reply back through the API: a summary of the order exactly as it was parsed — something like "2× Chicken Burger, 1× Fries, deliver to Green Town. Reply YES to confirm, or tell me what to change."

Why this matters more than it looks: the confirmation doubles as an error check. If the parser misread the order, the customer corrects it before anyone starts preparing anything. And customers stop sending "???" follow-ups, because they know the order landed.

Step 6: The human handoff rule

Anything the router can't confidently classify — complaints, unusual requests, a plain "call me" — does not get an automated guess. It gets flagged, written to a "Needs attention" list, and the owner gets a notification. A human takes over from there, in the same chat.

The gotchas (learned the hard way)

Always keep a human fallback. The goal is to remove repetitive work, not to remove humans. A bot that confidently misunderstands a customer is worse than no bot at all.
Never let a bot guess prices. Prices must come from your actual price list — a lookup in the same sheet — never from the parser's imagination. If the item or price isn't found, that's a handoff, not a hallucination opportunity.
Confirm before you commit. The confirmation message in Step 5 isn't politeness. It's your validation layer.
Log everything, even failures. The messages your automation can't handle are a goldmine: they're your next FAQ entries and your parser's best test cases.

This pattern generalizes

Swap "orders" for "bookings" and the same shape works in a lot of places:

Salons and barbers — booking requests get parsed into service + time, logged to a sheet, and confirmed automatically; rescheduling questions route to the FAQ path.
Clinics — appointment requests vs. general questions vs. "I need to speak to someone" (always a human, and fast).
Course sellers and coaches — lead qualification up front: which course, what level, ready to enroll or just curious — each answer gets a different follow-up.

The industries change. The pattern — trigger, parse, route, log, confirm, hand off — doesn't.

If you want the ready-made version

Full disclosure: after building this pattern more than once, I packaged it as WhatsAppKit — 4 production n8n workflows covering the four headaches from earlier: an Order Bot, a Lead Qualifier, an FAQ Bot, and an Opt-in Broadcast workflow. It's the same architecture described in this article, just pre-built and tested, so you can import it instead of wiring every node yourself.

It's $49 one-time on Gumroad, and the code WHATSAPP10 brings it to $39: https://onyxailabs.gumroad.com/l/ttxqw

The full catalog of tools is here, if you want to browse: https://onyxailabs.github.io/Catalog/

And honestly, if you'd rather build it yourself, everything above is genuinely enough to do it — that's the point of the breakdown.

What would you automate first in your business chats? Order-taking, FAQs, follow-ups — or something else entirely? I'm curious what breaks first in other people's inboxes, so drop it in the comments.

I Built a WhatsApp Order Bot with n8n — No Monthly Fees, It Runs on Your Own Server

Muhammad Mohsin — Thu, 22 Oct 2026 21:46:17 +0000

I Built a WhatsApp Order Bot with n8n

A small shop owner asked me a fair question: "Why does a WhatsApp bot cost $50 a month?"

He wasn't wrong to ask. Tools like ManyChat and WATI are good products, but for a business that mostly needs one thing — take orders and answer the same ten questions on WhatsApp — the pricing is hard to defend. Entry plans start around $15–25/month, the useful tiers climb past $50, and the bill arrives whether you sold anything that month or not. The bot is rented. Stop paying, and your order line goes silent.

So I built the version I could hand to someone like him: a WhatsApp order bot that runs on n8n, self-hosted, using Meta's official WhatsApp Cloud API. No per-message platform markup from me, no monthly fee to a bot vendor, and the whole thing lives on a server the shop owns. I later packaged my version as a kit, but everything below is the actual build — including the parts that broke.

What we're building (and what we're not)

The bot does three jobs:

Takes orders. A customer messages the number, the bot walks them through choosing items and quantities, confirms the total, and saves the order.
Answers FAQs. Prices, delivery areas, opening hours, payment methods — the questions every shop answers forty times a day.
Logs everything to Google Sheets. Every order lands as a row the owner can read, filter, and reconcile at night. No dashboard to learn.

What it does not do: it doesn't send bulk marketing blasts (Meta's rules, not mine — more on that below), it doesn't replace a human for complaints, and it doesn't pretend to be one. When a conversation goes off-script, the honest move is to hand it to the owner with a notification, not let an AI improvise.

The architecture, in plain words

Four pieces, each boring on its own:

WhatsApp Cloud API — Meta's official API. This is how real businesses are supposed to connect; the test number is free, and a real number runs on Meta's pricing, not a reseller's.
n8n (self-hosted) — the brain. One workflow receives messages, decides what they are, and sends replies. It runs on your own machine or a small VPS you control.
Google Sheets — the order book. Unsophisticated, and that's the point: the owner already knows how to read a spreadsheet.
One AI node — used narrowly, to draft replies for free-text questions the FAQ list doesn't cover. It drafts; the workflow decides whether to send.

Before you start

You need a Meta developer account, a phone number that is not currently registered on WhatsApp (a fresh SIM is easiest), an n8n instance reachable from the internet (webhooks need a public URL — n8n's tunnel works for testing, a domain is better for real use), and a Google account for the Sheet. That's the whole shopping list.

Step by step

1. Create the Meta app. In the Meta developer dashboard, create an app, add the WhatsApp product, and you'll get a test number plus a temporary access token. Send yourself a test message from the dashboard first — if that doesn't arrive, nothing downstream matters yet.

2. Connect your real number. Register the shop's number to the app. This is the point of no return for that number: it becomes a WhatsApp Business API number, so don't use your personal one. Generate a permanent access token with a system user — the temporary token expires in 24 hours, and a bot that dies daily is a special kind of embarrassment. (Ask me how I know a token can expire at the worst possible moment.)

3. Point the webhook at n8n. In n8n, start the workflow with a Webhook node set to receive POST requests, and paste its production URL into the Meta app's webhook settings, subscribed to the messages field.

4. Survive the verification handshake. This is where my own kit embarrassed me. When you save the webhook, Meta immediately sends a GET request with a challenge and expects your endpoint to echo it back — but only if the verify token matches the one you set. My shipped workflow failed this out of the box: the verification path wasn't handled, so Meta refused the webhook and the bot looked "connected" while receiving nothing. The fix is a small branch in the workflow: if the incoming request is a GET carrying hub.mode=subscribe, compare hub.verify_token against your token and return hub.challenge as plain text. Ten minutes of work, half a day to diagnose the first time. Test it before you build anything else on top.

5. Walk the workflow. A message arrives at the webhook as JSON. The flow I use:

An IF node separates real messages from status callbacks (delivered/read receipts arrive at the same webhook and will pollute your Sheet if you let them).
A CONFIG node (a plain Set node) holds every setting — more on this below.
Another IF routes by intent: a known FAQ keyword goes to a fixed reply; anything that looks like an order goes to the order flow, which asks for missing details one question at a time.
Orders get appended to the Sheet with timestamp, number, items, and total.
Replies go out through an HTTP Request node to the Graph API's /messages endpoint.

6. Send a test order. Message your own bot like a customer: ask about delivery, place an order, watch the row appear in the Sheet. Then break it on purpose — send a voice note, an image, a question it can't answer — and watch what it does. The failure cases are the product.

The CONFIG pattern

The single decision that made this maintainable: every token, number, and text string lives in one node named CONFIG, and nothing anywhere else in the workflow hard-codes a value.

{
  "phone_number_id": "YOUR_PHONE_NUMBER_ID",
  "sheet_id": "YOUR_GOOGLE_SHEET_ID",
  "store_name": "The Corner Store",
  "delivery_fee": 150,
  "ai_timeout_seconds": 300,
  "fallback_reply": "Thanks! The owner will reply shortly."
}

Every other node reads from it with expressions like:

{{ $('CONFIG').first().json.store_name }}

When the owner changes the delivery fee, there is exactly one place to edit. When a client deployment needs a different Sheet, one place. I learned this the scattered way first: hunting the same phone number ID through nine nodes is a rite of passage I don't recommend.

The 90-second lesson

Second scar, briefly: my AI node shipped with a hard-coded 90-second timeout. On a good day, replies drafted in seconds. On a slow day — a long question, a loaded model — the node hit 90 seconds and the whole run died silently. The customer got nothing, the Sheet got nothing. Timeouts on anything network-shaped should be configuration, not constants: mine now lives in CONFIG (see ai_timeout_seconds above) and defaults to a patient 300. If a setting can ruin a run at 2 a.m., it doesn't belong buried inside a node.

Honest limits

The 24-hour window. You can only send free-form replies within 24 hours of the customer's last message. Outside that window, Meta requires pre-approved template messages. Your order confirmations are fine (customers write first), but "we miss you" campaigns are a different, more regulated game.
Meta can say no. Numbers get quality-rated; spammy behavior gets them restricted. This bot answers people who message it — the safest possible posture — but no tool exempts you from the platform's rules.
It needs a home. Self-hosted means you host it. A small VPS or an always-on machine at the shop; if it sleeps, the bot sleeps.

What it actually costs

WhatsApp Cloud API: free to start; Meta charges per conversation beyond the free tier, priced by country — for a small shop, typically a few dollars a month, paid to Meta directly.
n8n: free, self-hosted.
Hosting: $0 on a machine you already own, or roughly $5/month for a small VPS.
Google Sheets: free.

Compare that with $50+/month for the rented version, forever. The trade is real, though: you own the maintenance too. That's the honest exchange — money, or responsibility — and different shops should choose differently.

If you'd rather not build it

I packaged my working version — the same workflow above, with the webhook verification fixed and the timeout configurable — as WhatsAppKit on Gumroad, setup guide included: onyxailabs.gumroad.com/l/whatsappkit. I also set it up for clients through my Fiverr gig if you'd rather hand the whole thing over. But genuinely: everything essential is in this article. A weekend and a fresh SIM will get you most of the way.

One question for the comments, from the build above: where do you stand on AI drafting replies for a small shop — helpful, or should a bot only ever send answers a human wrote word for word? I went with "AI drafts, rules decide," but I go back and forth on it.

Your PDF Files Should Never Leave Your Laptop

Muhammad Mohsin — Thu, 22 Oct 2026 12:10:39 +0000

A small experiment I want you to try

Take a PDF you actually care about — a contract, a bank statement, a scanned ID. Now go to any of the big "free PDF tools" websites and merge it with something, or compress it, or convert it.

Watch what happens. Your file uploads. Somewhere, a progress bar fills while your document travels to a server you've never heard of, in a country you didn't pick, where a copy of it sits for some amount of time you can't verify.

Those sites aren't villains. Uploading is just how they were built — ten years ago, browsers were too weak to do serious document work, so the server did it. The model stuck around because it's also convenient for them: your files on their disk, your traffic on their ads, your email on their signup form.

But the technical excuse expired a while ago. Modern browsers run WebAssembly at near-native speed. Your laptop is, quietly, a very capable PDF machine. The upload is a habit, not a necessity.

What I built instead

I'm Muhammad Mohsin, a developer running a small studio called Onyx AI Labs. I built OnyxPDF — onyxailabs.github.io/onyxpdf — a set of 50 PDF and image tools that run 100% in your browser.

No upload. No account. No "create a free account to download your file." You open the page, pick a tool, and the work happens on your device. Close the tab and there's nothing of yours anywhere, because there never was.

The tools people actually need are all there:

The daily drivers — merge, split, compress, rotate PDFs; convert to and from Word, images, CSV; JPG to PDF and back.
Real security — protect and unlock PDFs with actual AES-256 encryption done locally with WebAssembly, not the fake "password" some sites apply. A contract you encrypt on your own machine never exists unencrypted anywhere else. That sentence cannot be true of an upload-based tool.
OCR in 7 languages — turn scanned documents into searchable text, on-device.
Sign and fill forms — the two things people upload the most sensitive documents for.
An image bench too — compress images (including to a target file size), convert formats including HEIC to JPG, make favicons, blur or pixelate the parts of a screenshot you'd rather not share.
A background remover — this is the one that convinced my friends. Background removal is the poster child of "upload your photo to our AI server." OnyxPDF runs an open model (DIS IS-Net, converted to ONNX) right in the browser. Slower than a server farm the first time it loads the model — and your photo never leaves the room.
A passport photo maker — think about what a passport photo is. Handing it to a random upload site so it can crop it for you is a trade nobody should have to make.

The honest limits

I'd rather lose a reader to honesty than keep one with a pitch, so:

Your device does the work, so your device sets the ceiling. A huge PDF on an old phone with little memory will struggle or fail where a server wouldn't blink. For normal documents — the contracts, forms, scans and images of everyday life — it's a non-issue.
There's no server-side batch pipeline. If your job is processing ten thousand PDFs overnight, you want a server and a script, not a browser tab. This tool is for humans doing document tasks, one at a time, privately.
I'm not the only one doing this. Other no-upload tools exist, and some are good. My wedge is simple: 50 tools, free, no sign-up wall, and the files genuinely never move.

There are also a few lines I won't cross for features' sake — everything on the site states its real limits rather than faking capabilities (the compression is honest about what browser-side compression can do, for instance). A tool that handles your private documents should start by not lying to you.

Don't trust me — check

The nice thing about this claim is that you don't have to take my word for it. Load the site once, then switch your device to airplane mode and run a tool. Everything still works, because there's no server in the loop to disconnect from. Or open your browser's network tab and watch while you process a file: after the page itself loads, your document generates no traffic. "Files never upload" is a testable statement, and I'd rather you test it than believe it.

Why free?

Because the architecture makes it cheap. Static hosting, your CPU, no server bill — "free" is easy to promise when there's almost nothing to pay for. That's also the quiet argument for local-first tools in general: when the user does the computing, the business model doesn't need the user's data or the user's subscription.

Next time a PDF site asks you to upload a document, ask the question I started asking: does this actually need my file, or does it just want it?

For most everyday tasks, your browser already knows the answer.

OnyxPDF is live and free at onyxailabs.github.io/onyxpdf — try the background remover on a photo you'd never upload anywhere. That feeling is the whole point.

I Stopped Renting My YouTube Growth Tools

Muhammad Mohsin — Thu, 22 Oct 2026 12:08:43 +0000

The bill I got tired of paying

When I started taking my YouTube channel seriously, I did what everyone does: I installed TubeBuddy and vidIQ, clicked around for a few days, and hit the paywall right where the useful stuff lives.

Keyword scores? Paid tier. Competitor tracking? Paid tier. The audit that actually tells you what's wrong with your channel? You guessed it.

Now, neither tool is a scam. They're mature products with big teams, and if you're pulling real money out of a channel, $10–$20 a month is nothing. But I was a beginner with a tiny channel and a simple problem: I was renting software to grow something that hadn't earned its first dollar yet. Every month the meter ran whether my videos did well or not.

So I went looking for a TubeBuddy alternative that didn't charge rent. Here's what I actually found, including the thing I built when the search came up short.

Option 1: TubeBuddy's free tier

TubeBuddy's free plan is fine for the basics — some tag suggestions, a checklist when you upload, a thumbnail generator that's okay for quick work. The catch is the same as every freemium tool: the features that change decisions (keyword explorer depth, bulk processing, A/B testing, competitor scorecards) sit behind the paid plans. It's a demo wearing a free costume.

Option 2: vidIQ's free tier

Same story, different accent. vidIQ's free version gives you a score for your video and some keyword data, and the daily ideas feature is genuinely fun. But the deep keyword research, channel audit depth, and competitor views are subscription territory. Credit where it's due: vidIQ's free tier taught me more in a week than most blog posts did. Then it asked for a card.

Option 3: Keywords Everywhere (the one subscription I respect)

If you want a genuinely cheap paid option, Keywords Everywhere is a browser extension that shows search volume and related keywords right inside YouTube and Google. It runs on credits rather than a flat monthly fee, so light users pay light prices. It's not a full growth suite — no channel audits, no competitor compare — but as a keyword data layer, it's honest pricing and I still recommend it to people who ask.

Option 4: Build it. (Yes, seriously.)

Here's the part where I'm supposed to pretend I found a perfect tool. I didn't. I found a gap, got annoyed, and built the thing.

I'm a developer by trade, so I asked a rude question: what do these tools actually do? Most of it is the YouTube Data API — which Google gives every creator for free, with their own API key — plus some scoring logic and a decent interface. The "AI" parts aren't magic either.

So I built OnyxIQ, a YouTube growth studio that works like this:

You plug in your own free YouTube API key (the setup walks you through it). Your quota is yours, so there's no user cap and no middleman server metering you.
Channel X-Ray — scores your whole channel and points at what's leaking views.
Video X-Ray — the same treatment for a single video before or after you publish.
Keyword Lab — keyword ideas with demand scores, so "what should I make next?" stops being a guess.
Competitor Compare — put any channel next to yours, side by side.
Thumbnail Feed-Test — drops your thumbnail into a simulated feed next to the actual top rivals for your keyword, so you see what viewers see. (It doesn't design thumbnails for you — it shows you the fight your thumbnail is walking into.)
AI Studio — helps draft titles, descriptions, tags and hooks in English or Roman Urdu.
Upload Checklist — the boring pre-publish stuff, checked before you hit the button, not after.

It's a Chrome extension plus a PWA. Basic is free. Prime is $49, once — not per month, not per year. Once.

The honest part

Let me say the things a sales page wouldn't:

TubeBuddy and vidIQ are more mature than OnyxIQ. Bigger feature lists, bigger teams, years of polish. If you need A/B thumbnail testing or enterprise anything, they're ahead, full stop.
OnyxIQ is new. I'm one developer, not a company with a support floor. It covers the core growth loop — audit, keywords, competitors, thumbnail test, upload — and that's the promise, not "everything they have, cheaper."
Sign-in is a work in progress. OnyxIQ can sign in with Google, but I'm still completing Google's verification for that flow, so you may see an "unverified app" notice there. The API-key route — the main way the tool is designed to run — doesn't have that issue, because the key is yours.
$49 once only works because there's no server bill. Your browser does the work with your key. That's the whole trick behind "no subscription," and it's also the limit: no cloud sync across machines like the big tools have.

Who should pick what

Making real money from a channel already? TubeBuddy or vidIQ, paid, no shame. The time they save is worth more than the fee.
Want keyword data only, cheap? Keywords Everywhere.
Small channel, tired of rent, want the core toolkit owned outright? That's exactly the hole OnyxIQ was built to fill.

If you want to look before you judge: the full breakdown is on the OnyxIQ page, the free Basic tier is on Gumroad, and Prime is here if the free one earns it. I also recorded the whole thing working on a real channel — launch video's on YouTube, no staged screenshots.

I don't know if "own your tools" becomes a movement or stays a niche preference. I just know my growth software stopped billing me every month — and that part already feels like a win.