A CRM where the AI never leaves your laptop

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:

1. Paste the conversation → Analyze with a local model
2. Model returns a validated JSON lead: client, company, project, budget, priority, timeline, status, tags
3. Review step — nothing is saved until you approve it (a 1.5B model is confidently wrong sometimes, so a human is the last gate)
4. 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. <!-- TODO: drop a Loom/YouTube walkthrough URL in here before publishing -->

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.

12 of 10 messages