DEV Community: Pratik

A CRM where the AI never leaves your laptop

Pratik — Fri, 16 Oct 2026 08:06:59 +0000

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

What I Built

Private AI Lead Assistant — a small CRM where you paste a client conversation and a local model turns it into a structured lead.

A freelancer's WhatsApp or email thread with a prospect is already a CRM record in prose: who they are, what they want built, the budget, the deadline. Extracting it is tedious, and every cloud "AI CRM" solves it by uploading the transcript. This solves it on your own machine:

Paste the conversation → Analyze with a local model
Model returns a validated JSON lead: client, company, project, budget, priority, timeline, status, tags
Review step — nothing is saved until you approve it (a 1.5B model is confidently wrong sometimes, so a human is the last gate)
Open the lead → draft a follow-up message or a full project proposal, then copy it out

Who would pay for it: freelancers and 2–10 person agencies. Client conversations contain budgets, deadlines and NDA'd product plans; per-seat AI CRM pricing is hard to justify when you invoice by the project. Running extraction locally makes the marginal cost $0 — which is the difference between a side hustle's tooling and a SaaS bill.

Stack: React 19 + Tailwind, Express, Postgres, TypeScript, and Qwen 2.5 (1.5B, open weights) served by Ollama — no external AI API anywhere in the codebase.

Demo

The app runs on localhost by design — the point is that the conversation never leaves the laptop, so there is no hosted demo to link.

Run it: npm install && npm run db:migrate && npm run dev (with Ollama up and ollama pull qwen2.5:1.5b) → client on :5173, API on :3001.

What a full session looks like (real run against qwen2.5:1.5b):

Register → land on the dashboard
Paste a chat where a restaurant owner in Kathmandu asks for an online ordering system
POST /api/ai/analyze → ~36s cold → extraction: Sita Gurung · ABC Restaurant · "online ordering system" · 40,000–60,000 NPR · high priority
Review, approve → lead appears in the list, searchable by q=ABC
Open lead → Generate follow-up (~26s) → Generate proposal (~26s)
GET /api/health → {"status":"ok","db":"up","ai":"up","model":"qwen2.5:1.5b","provider":"ollama"}

Code

Three pieces that make a small local model trustworthy:

1. Constrained decoding + determinism. Extraction is a structured prediction, so the request carries a JSON Schema (format) and fixed sampling — same conversation, same lead:

/** Deterministic extraction: temperature 0 + fixed seed + explicit context budget. */
export const EXTRACTION_OPTIONS = {
  temperature: 0,
  seed: 42,
  numCtx: 8192,
  numPredict: 512,
} as const;

export async function analyzeConversation(ai: AiProvider, conversation: string) {
  const raw = await callAi(ai, buildLeadExtractionPrompt(conversation), {
    system: LEAD_EXTRACTION_SYSTEM,
    format: leadExtractionJsonSchema, // Ollama constrained decoding
    ...EXTRACTION_OPTIONS,
  });
  return parseLeadExtraction(raw);
}

2. Never trust the model's JSON. LLM output crosses a Zod boundary, or the request fails with a 502 the UI can show:

/** LLM -> JSON -> Zod. Rejects with a useful 502 instead of trusting the model. */
const result = leadExtractionSchema.safeParse(parsed);
if (!result.success) {
  const details = result.error.issues
    .map((issue) => `${issue.path.join('.') || '(root)'}: ${issue.message}`)
    .join('; ');
  throw new HttpError(502, `AI returned data that failed validation: ${details}`);
}

3. Prompt injection is a real risk with paste-anything input. I measured the 1.5B model failing to resist injections in the eval harness, so protection is layered: the system prompt treats conversation text as untrusted data, a detector flags instruction-shaped text before it reaches the model, and the review UI warns you:

const INJECTION_PATTERNS: RegExp[] = [
  /ignore\s+(?:all\s+|any\s+)?(?:previous|prior|earlier|above|preceding)\s+instructions?/i,
  /\[system\]/i,
  /<\s*system\s*>/i,
  /pretend\s+(?:to\s+be|you\s+are)\s+(?:an?\s+)?(?:system|developer|assistant)/i,
];

export function detectPromptInjection(text: string): string | null {
  for (const pattern of INJECTION_PATTERNS) if (pattern.test(text)) return PROMPT_INJECTION_WARNING;
  return null;
}

How I Built It

Open-weight model, local inference: Qwen 2.5 1.5B through Ollama — pulled once, works offline, zero API keys. The 1.5B size is deliberate: it runs on a laptop CPU and keeps the whole thing free, which is what makes it a side hustle tool rather than another subscription.
Provider abstraction: AiProvider (health() / generate(prompt, options)) with format: 'text' | 'json' | object for constrained decoding. Swapping to llama.cpp or a bigger Qwen is one class.
Different sampling per task: extraction and proposals run at temperature: 0, seed: 42; follow-ups run at 0.7 so regenerating gives you a different email instead of the same one.
A 29-conversation eval harness (npm run ai:eval -w server) that prints Expected / Actual / Pass-Fail per case — this is how I found the model's habits, e.g. defaulting priority: "medium" when the chat never mentions urgency, which is exactly why the review step exists.
Around it: React 19 + Tailwind (dark mode, toasts, skeletons, keyboard shortcuts), Express with Zod validation, bcrypt auth, rate limits, allow-list CORS, Drizzle on Postgres with ilike search, 109 tests, and a Docker Compose dev stack (React + Express + Postgres, Ollama as an optional profile).

Getting the containers talking took the usual compose lesson — localhost inside a container is the container, so the Vite dev proxy switches to the compose service name:

proxy: { '/api': { target: process.env.VITE_API_PROXY ?? 'http://localhost:3001', changeOrigin: true } }

(I got this from The 'Localhost' Trap: Networking Microservices in Docker Compose by Omar Lashin, and the whole local-first framing echoes How I Built a Zero-API-Cost AI Agent That Runs 100% Locally — No Keys, No Cloud, No Bills by scriptgather.)

Why Does Open Innovation Matter?

For this project it isn't a preference — it's the product:

The data can't leave. Client budgets and NDA'd plans are the input. A closed API means every paste is a disclosure; local inference means the transcript stays on disk.
$0 marginal cost. The business case for a freelancer is "extract leads for free forever," not "another $20/token-metered seat."
No lock-in or pricing risk. The model is a file you ollama pull. If Qwen's license, pricing, or availability changed tomorrow, the pipeline wouldn't notice — and the AiProvider interface means the vendor layer was never load-bearing.
Open weights make the limitations debuggable. I could evaluate the 1.5B model against 29 realistic conversations and see where it's weak (prompt injection, unstated priority), then engineer around it with a review gate and a detector. With a closed API you only get vibes — and when their model version changes under you, your prompts silently break.
Room to fine-tune for the niche. The extraction schema is domain-specific (budget ranges in local currency, project tags). With open weights, a few hundred in-domain examples can specialize it — something a general API handles poorly and you can't tune at all.

My Agent Session

The full build session — verifying Phases 17–24 of the PRD, writing the Docker stack, the dark-mode sweep, the live end-to-end run against the local model, and drafting this post:

Finishing the Private AI Lead Assistant (PRD Phases 17–24) + Hacktoberfest submission post

You

Continue the PRD for private-ai-lead-assistant — Phases 17–24: search/filter, error handling, testing, security, Docker dev environment, UI polish, documentation, and the final MVP demo.

Agent

Verifying Phases 17–20 first — the search/filter code, error middleware, test suites, and security measures looked already implemented. Confirming before writing anything new.

▸ grep_search listLeads q status priority followUp

Input

listLeads q status priority followUp

Output

lead.service.ts:40 — plain ilike search over client/company/project; LeadsList.tsx has selects + chips

▸ bash npm test (server + client)

Input

$ npm test (server + client)

Output

92 server tests + 17 client tests pass

Agent

Phases 17–20 confirmed complete. Building Phase 21: Docker dev environment — root multi-stage Dockerfile, compose stack (db/server/client + optional ollama profile), and a VITE_API_PROXY so the Vite dev proxy targets the compose service name instead of localhost.

▸ write Dockerfile, .dockerignore, docker-compose.yml

Input

Dockerfile, .dockerignore, docker-compose.yml

Output

node:22-alpine multi-stage (base/server/client), npm ci, migrate-then-dev on server, profiles: ["ollama"] with host.docker.internal:host-gateway

▸ edit client/vite.config.ts — proxy target

Input

client/vite.config.ts — proxy target

Output

process.env.VITE_API_PROXY ?? 'http://localhost:3001', host: true

Agent

Phase 22 (UI polish): dark mode with a pre-paint inline script in index.html to avoid a flash of wrong theme, Toast/Skeleton/ConfirmDialog/Shortcuts components, centralized light/dark class sets in lib/ui.ts, then a full sweep adding dark: variants across all 15 UI files (grep-verified zero missing pairings).

▸ grep_search dark: pairing sweep across client/src

Input

dark: pairing sweep across client/src

Output

0 missing dark: variants

Agent

Phase 23 (docs): README rewritten with all 14 required sections + a Browser → Express → AI Service → Ollama → Qwen diagram and an API appendix; AGENTS.md phase list corrected. Phase 24 (demo): running the full flow live against the real local model.

▸ bash register → /api/ai/analyze → create lead → search → follow-up → proposal (cur...

Input

$ register → /api/ai/analyze → create lead → search → follow-up → proposal (curl, cookie jar)

Output

qwen2.5:1.5b extracted Sita Gurung / ABC Restaurant / online ordering system / 40,000–60,000 NPR; analyze 36s cold, follow-up 26s, proposal 26s; health: provider=ollama

Agent

Final verification: typecheck clean, 17 client + 92 server tests pass, production build succeeds (355 kB js / 29 kB css). Docker stack authored and YAML-validated but not executed — no Docker daemon in this WSL distro.

You

What did we do so far?

Agent

Delivered a per-phase status report (17–24, with which were pre-existing vs newly built), verification results, caveats, and closed with the Community Wisdom citations that shaped the Docker networking and dark-mode work.

You

Write the Hacktoberfest Open-Source AI Challenge Week 2 (Side Hustle) submission post using the challenge template.

Agent

Grounded the draft with a semantic search on DEV for local/zero-API-cost AI builds, checked the challenge's full_details (deadline Oct 18 11:59 PM PDT, required tag #hf26challenge), verified tag existence, and staged an unpublished draft: "A CRM where the AI never leaves your laptop" with the template sections filled, two honest TODO markers (video link, repo embed), and the My First User / Prize Categories sections removed per template instructions.

▸ create_article title: A CRM where the AI never leaves your laptop; tags: hf26challenge, ai, ...

Input

title: A CRM where the AI never leaves your laptop; tags: hf26challenge, ai, opensource, privacy; published: false

Output

draft id 4860930, edit_url returned

You

yes

Agent

Saving this session transcript, embedding it in the draft's My Agent Session section, then publishing.

Bato — Plan at home. Hike offline. Phone in your pocket. 🥾

Pratik — Thu, 08 Oct 2026 15:26:30 +0000

What I Built

Bato is an offline-first trail companion PWA.

Upload a GPX file, enter your start time and fitness level, and Bato generates a simple one-page hiking plan with:

Distance and elevation gain/loss
Highest point and elevation profile
Estimated hiking time
Sunrise and sunset
Latest safe turnaround time
Pacing, rest, water, and safety guidance

The goal is simple: plan at home, then put your phone away and hike.

Demo

GitHub: https://github.com/PRDXdotEXE/Bato

Live Demo: https://baato-beige.vercel.app/

Code

Repository: https://github.com/PRDXdotEXE/Bato

How I Built It

Bato is built with:

Next.js + TypeScript
Tailwind CSS
WebLLM
Qwen 1.5B Instruct, quantized
SunCalc
IndexedDB
Service Worker / PWA

The GPX is parsed entirely in the browser. Distance, elevation, hiking time, sunrise/sunset, and turnaround time are calculated using deterministic TypeScript.

The local LLM does not calculate these values. It only turns the verified numbers into a short, human-readable hiking plan.

If the model fails to load or the device is too weak, Bato falls back to a deterministic template, so the app always produces a plan.

There is no backend or runtime API dependency. After the initial model download, Bato can work offline.

Why Does Open Innovation Matter?

Using an open-weight model makes local inference possible.

Instead of sending trail data to a remote AI API:

GPX → Local calculations → Local LLM → Hiking plan

Everything stays on the device.

This makes Bato more suitable for hiking, where internet connectivity may be unavailable, while also giving the project freedom to swap and experiment with different open-weight models.

Prize Categories

Open-Weight / Open-Source AI
Local / On-Device AI
Touch Grass / Offline-first

Recipe-maker

Pratik — Sun, 04 Oct 2026 08:24:56 +0000

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

What I Built

I built Family Recipe Memory for a friend whose family cooks almost entirely from memory.

Her grandmother and parents never write recipes down or measure much. They explain them out loud: add some of this, cook it until it smells right, you'll know when it's done.

Those little details are the actual recipe, and they're very easy to lose. Right now, a lot of them live in voice notes buried somewhere in a chat app, often in a mix of Nepali and English, with no practical way to search them.

So the app lets her just talk.

She uploads a voice note, and it:

Transcribes it on her own machine
Lets her fix any misheard words
Turns it into a clean recipe with ingredients, steps, tips, and the family story
Saves it to a small recipe library
Lets her ask things like "What did Grandma say about making momo?"

One rule I cared about: if something wasn't said in the recording, the app leaves it blank instead of guessing. I didn't want a model quietly rewriting someone's grandmother's recipe.

Demo

[https://www.youtube.com/watch?v=x8TJe7HyIew]

The flow is:

Upload voice note → Transcribe → Review transcript → Extract and save → Browse or ask questions

Each recipe is shown as a card with the story, an ingredients table, numbered steps, and tips. Recipes can also be downloaded as Markdown.

Code

PRDXdotEXE / recipe-maker

🍲 Family Recipe Memory

Preserve voice recipes and stories from loved ones using Local AI + Backboard Persistent Memory.

Problem

Family culinary heritage is often trapped in unwritten spoken traditions. Audio notes from grandmothers or parents contain precious nuances, but searching through raw voice recordings is frustrating and inefficient.

Solution

Family Recipe Memory turns unstructured voice notes into a searchable family knowledge base. Audio transcription and AI structured parsing run 100% locally, ensuring raw voice recordings never leave your machine. Only extracted text is persisted in Backboard memory for cross-session natural language retrieval.

Architecture & Privacy Model

View on GitHub

How I Built It

Everything runs locally.

The stack is Python and Streamlit, with two open models doing the heavy lifting:

OpenAI Whisper for speech-to-text. The voice notes mix Nepali and English, and the smallest Whisper model gets shaky on that, so the app defaults to small, lets you switch to medium, and lets you pick the spoken language.
Ollama for everything language-related. I tested with llama3.2, gemma2, and qwen2.5, and the app lists whichever models are installed.

The extraction step was the part that took the most care.

The transcript goes to the model with strict instructions: only use what was said, keep dish and ingredient names as spoken, and leave anything that wasn't mentioned empty.

The output is JSON, which I then clean up, because small local models love to return a quantity as an object or write "N/A" instead of leaving a field empty.

Two design choices came directly from using it:

A review step between transcription and extraction. Speech-to-text can mishear a Nepali word now and then, and one wrong word can ruin an ingredient. Letting my friend fix the transcript first made the recipes noticeably better.
Memory is just a local JSON file. Recipes are saved to data/recipes.json. For questions, the app passes the most relevant saved recipes to the local model and tells it to answer only from them, and to say so if the answer isn't there.

I also had a bug early on where the results disappeared the moment I clicked the download button, because Streamlit reruns the script on every click. Moving the state into st.session_state fixed it.

My friend's reaction: [Add your friend's actual feedback here, or remove this line.]

Why Does Open Innovation Matter?

A family voice note isn't just audio. It's someone's voice, their stories, names, and private conversations, often from people who are getting older. I wasn't comfortable sending that to a cloud API just because it was convenient.

Open models meant the whole pipeline—from audio to transcript to recipe to answers—runs on a laptop with no account, no API key, and no per-request cost.

It also meant I could test the extraction prompt as many times as I liked on real recordings without worrying about a bill, and I could swap models freely when one handled Nepali words better than another.

A closed API could have done the extraction too. What it couldn't give me is the same level of control over keeping the original recordings on my friend's computer.

For this project, that mattered more than anything else.

Prize Categories

Build for a Friend / Loved One