DEV Community: Sanket Deore

PitchPilot

Sanket Deore — Fri, 23 Oct 2026 15:04:34 +0000

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

What I Built

I built PitchPilot, a local AI assistant that helps freelancers and solo creators turn rough client notes into polished project proposals, scope documents, estimates, and follow-up messages.

The problem is simple: doing the actual work is often easier than selling the work.

A freelancer might receive something like:

Need a landing page for our new product.
Probably 5 sections.
Need it by next Friday.
We already have branding.
Budget around $800.

PitchPilot turns that into a structured draft containing:

project summary
deliverables
scope boundaries
estimated timeline
pricing breakdown
assumptions
revision limits
suggested next steps
client follow-up message

Instead of spending 30–60 minutes writing a proposal from scratch, the freelancer gets a usable first draft in seconds and only needs to review it.

The people who could pay for it are freelancers, consultants, developers, designers, marketers, photographers, and other solo service businesses that repeatedly write proposals for potential clients.

The business model could be a simple one-time paid desktop app instead of another monthly AI subscription.

Demo

The demo starts with an intentionally messy client request:

Shopify store redesign.
Around 12 products.
Client wants something cleaner and faster.
Need mobile optimization.
Maybe newsletter setup too.
Budget is around $1,500.
Would like it done in three weeks.

PitchPilot converts it into a structured proposal containing a clear scope, milestones, deliverables, estimated price, exclusions, and a ready-to-send client message.

Because inference runs locally, the client brief never needs to leave the freelancer's computer.

Demo:

[ADD YOUR DEMO / VIDEO LINK HERE]

Code

PitchPilot is open source and designed to run locally.

Repository:

[ADD YOUR GITHUB REPOSITORY HERE]

A typical setup looks like:

git clone [YOUR_REPOSITORY]
cd pitchpilot

pip install -r requirements.txt

ollama pull qwen3:4b

python app.py

No AI API key is required.

Once the model is downloaded, proposal generation can run locally.

How I Built It

PitchPilot uses Ollama for local inference and an open-weight Qwen3 model as its reasoning and writing engine.

The application takes an unstructured client brief and combines it with information such as:

Service: Web development
Hourly rate: $60
Minimum project: $500
Revisions included: 2
Typical delivery: 2-4 weeks

Instead of asking the model to generate one giant block of text, PitchPilot first generates structured proposal data.

For example:

{
  "project_title": "Shopify Store Redesign",
  "deliverables": [
    "Responsive Shopify storefront redesign",
    "Mobile optimization",
    "Product page improvements",
    "Newsletter signup integration"
  ],
  "timeline": "3 weeks",
  "estimated_price": 1500,
  "revisions": 2
}

The application validates that structure and then turns it into the final client-facing proposal.

I separated the project into a few simple layers:

Client Brief
     ↓
Open-Weight Model
     ↓
Structured Proposal
     ↓
Validation
     ↓
Proposal / Estimate / Client Message

The model is also configurable.

For example:

python app.py --model qwen3:4b

can be changed to another locally installed compatible model.

That means users are not locked into the model I originally selected.

The open model is not just an extra feature. It handles the main value of the application: understanding an incomplete client request and converting it into a professional business document.

Why Does Open Innovation Matter?

Open innovation matters here because freelancers regularly work with information that should not automatically be sent to an external AI provider.

A client brief might contain:

Unreleased product details
Internal company problems
Customer information
Pricing
Budgets
Credentials
Contract requirements
Business strategy

With PitchPilot, that information can stay on the freelancer's own machine.

That is particularly important for freelancers working under NDAs or handling confidential client projects.

Running an open-weight model also changes the economics.

If someone generates dozens of proposals every month through a paid API, every generation has a cost.

With local inference, the user can download the model once and keep using it without paying for every proposal.

It also gives me control over the product.

I can:

change the system prompt
add industry-specific proposal styles
switch models
run smaller models on lightweight hardware
use larger models when more compute is available
fine-tune a model for a particular profession
build offline workflows
avoid depending on one AI vendor

A closed API could generate proposals too.

But an open-weight model makes it possible to build PitchPilot as a tool the freelancer can actually own rather than another service they permanently rent.

For a project aimed at helping people make money from their skills, that difference matters.

My Agent Session

I used an AI-assisted development workflow while designing PitchPilot, particularly for exploring the architecture, defining the structured-output format, improving the local inference workflow, and thinking through the freelancer experience.

DevRelay session:

[ADD YOUR DEVRELAY SESSION HERE]

SlothSort

Sanket Deore — Fri, 23 Oct 2026 14:12:58 +0000

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

What I Built

I built SlothSort, a local AI file organizer for people who keep saying, “I’ll clean that folder later.”

You point SlothSort at a messy folder like Downloads, Desktop, or a project dump, and it uses a locally running open-weight model to suggest:

cleaner filenames
sensible folders
which files belong together
a short explanation for every decision

The important part: SlothSort does not immediately move anything.

It creates a dry-run plan first, so I can review what the AI wants to do before applying it.

The workflow is basically:

slothsort ~/Downloads

Review the plan.

Then, if it looks good:

slothsort ~/Downloads --apply

It turns a task I repeatedly procrastinate on into something closer to approving a checklist.

Very sloth-friendly.

Demo

The demo shows SlothSort taking a deliberately messy folder containing screenshots, PDFs, invoices, notes, images, and random downloads and turning it into a clean organization plan.

Because the model runs locally, the demo also works without sending the filenames or file contents to an external AI service.

Demo:

[ADD YOUR DEMO / VIDEO LINK HERE]

Code

The project is open source and designed to be easy to run on a normal laptop.

Repository:

[ADD YOUR GITHUB REPOSITORY HERE]

The basic setup is:

git clone [YOUR_REPOSITORY]
cd slothsort

pip install -r requirements.txt
ollama pull qwen3:4b

python -m slothsort ~/Downloads

SlothSort defaults to preview mode, so nothing is changed unless --apply is explicitly provided.

How I Built It

SlothSort is built around local inference with Ollama and an open-weight Qwen3 model.

Instead of asking the model for a paragraph describing what it thinks should happen, SlothSort requests structured output representing a file-operation plan.

Conceptually, the model receives metadata such as:

IMG_4821.png
bank_statement_june.pdf
Screenshot 2026-10-18.png
notes-final-final2.txt
invoice_acme_1042.pdf

and returns structured suggestions similar to:

{
  "operations": [
    {
      "source": "invoice_acme_1042.pdf",
      "destination": "Finance/Invoices/Acme_Invoice_1042.pdf",
      "reason": "The filename indicates that this is an invoice from Acme."
    }
  ]
}

The application validates that plan before touching the filesystem.

I intentionally separated the AI decision layer from the file-operation layer.

The model can suggest actions, but ordinary application code decides whether those actions are valid and safe.

That also makes the model replaceable.

For example:

slothsort ~/Downloads --model qwen3:4b

can be changed to another locally available model without rewriting the application.

The AI is not an optional chatbot bolted onto the project. The open-weight model is the component doing the tedious part: interpreting messy human filenames and turning them into useful organization decisions.

Why Does Open Innovation Matter?

For this project, running an open-weight model locally changes the product itself.

A file organizer can see surprisingly personal information.

Even filenames can reveal things like:

medical_results.pdf
salary_revision.pdf
passport_scan.jpg
client_contract_draft.docx

I did not want organizing those files to require sending that information to a server I do not control.

With local inference, the workflow can stay on the user's machine.

There is another advantage: SlothSort is not tied to one AI provider.

If a different open model works better, I can swap it.

If I want a smaller model for an old laptop, I can use one.

If I want a larger model on a workstation, I can use that instead.

If I want to customize the prompts or fine-tune a model around a specific filing system, I can do that too.

There is no API key required for every run, no per-file inference bill, and no dependency on a remote service remaining available.

A closed API could certainly classify files, but the open approach gives this particular project the properties I actually wanted:

privacy, offline operation, model choice, hackability, and local ownership.

Those are not implementation details here. They are features.

My Agent Session

I used an AI-assisted development workflow while designing and building SlothSort, including thinking through the architecture, safety boundaries, CLI experience, and local-model integration.

DevRelay session:

[ADD YOUR DEVRELAY SESSION HERE]

The Lazy Payoff

File organization is rarely difficult.

It is just annoying enough to keep postponing.

Normally the workflow looks like this:

open file → figure out what it is → decide where it belongs → rename it → move it → repeat 50 times

With SlothSort, it becomes:

scan folder → review plan → approve

I still keep the human in control, but I remove most of the tiny repetitive decisions.

That is the kind of laziness I wanted for this challenge: not avoiding useful work entirely, but letting the computer handle the boring part so I only have to make the decisions that matter.

Slow and steady.

Preferably while doing almost nothing.

I built a tool to help my friend in the next interview.

Sanket Deore — Sat, 03 Oct 2026 17:42:34 +0000

PostMortem
What I Built

A close friend of mine had just finished another tech interview and sat there trying to explain to me how it went. She remembered the questions and her answers, but she couldn't figure out what went wrong. No feedback, no reply, just silence. She was giving interview after interview and getting more demoralized every time.

Getting rejected in tech interviews sucks, but getting ghosted and never knowing why is worse.

So I built PostMortem for her. It is an interview post-mortem app designed for one person to dump an interview the exact way she remembers it. The app automatically tags her weak spots like rambling or missing metrics, and counts which mistakes keep showing up across multiple interviews. It generates targeted practice drills to help her fix them.

It has three parts:

Debrief

Saves the company, role, outcome, and her raw Q-and-A text dump, then tags each answer.

Patterns

Totals those tags across interviews with trend arrows and streak counters.

Drill

Asks five practice questions, scores her responses, and rewrites a stronger version of what she actually said.

Demo

Live URL: https://post-mortem-iota.vercel.app/

Code

GitHub Repo: https://github.com/sanketdeore/PostMortem

PostMortem

An interview post-mortem coach for one person.

She does the interview, gets rejected or ghosted, and never learns why. Rejections never come with feedback.

PostMortem turns the interview the way she remembers it — a messy Q: / A: dump, or a voice note — into the weakness that keeps showing up, then gives her a drill aimed at that weakness.

Open-source models only. Nothing in this repo calls OpenAI or Anthropic. Every model call goes through Ollama on her machine, Backboard's open-weight models, or a Tinker fine-tune. With no keys set, the heuristic analyzer still tags answers.

What It Does

Debrief. Company, role, outcome, and a dump of what they asked and what she said. Optional .m4a / .mp3 voice note, transcribed locally with faster-whisper and deleted. The audio never leaves the machine.

Patterns. Weakness tags counted across interviews (no_metrics — 7x in 4 sessions), with trend arrows and streak counters.

Drill. Five targeted practice questions based on recurring weaknesses. Responses are scored and rewritten into stronger versions of what she actually said.

How I Built It

PostMortem is built around open-weight models with flexible inference backends chosen by an ANALYZER setting in .env:

Debrief (POST /debrief)
│
▼
Split Q/A
│
▼
analyze()
│
▼
SQLite (weakness_tag)
│
├──────────────────────────────┐
│ │
▼ ▼
Patterns (GET /patterns) Drill (POST /drill/start)
│ │
│ ▼
│ 5 Questions
│ │
│ ▼
│ Score & Rewrite
│ │
│ ▼
│ Backboard Thread
│
└──── Count tags & Read Backboard

Local Inference with Ollama

By setting ANALYZER=ollama, PostMortem runs qwen2.5:7b completely locally on her laptop.

Every model response is strictly parsed into JSON and checked with Pydantic. If an LLM returns bad JSON or hits a network error, it cleanly falls back to a rules-based heuristic tagger so the app never crashes.

Local Audio Transcription

If she records a voice memo right after an interview, she can upload .m4a or .mp3 files.

The server transcribes them locally using faster-whisper, drops the text directly into the debrief textarea, and deletes the audio file immediately.

Backboard Dual Integration

Backboard does two separate jobs using open-weight models via the OpenRouter provider.

First, when ANALYZER=backboard, BackboardAnalyzer tags answers with memory=off and json_output=true without writing to a thread.

Second, on every scored drill — even when using the heuristic tagger — it appends the question, score, and top tags onto a single persistent Backboard assistant thread with memory=Auto.

The Patterns page reads that thread back so her practice history persists across sessions.

Fine-tuning with Tinker

I used Tinker to LoRA fine-tune Qwen3-8B on her labeled interview answers (data/train.jsonl).

I used Qwen3-8B here because Tinker does not serve Qwen2.5-7B, the model I run locally with Ollama.

When ANALYZER=tinker, PostMortem samples the saved checkpoint.

On a held-out test set of [N] answers, the fine-tuned model achieved 0.50 precision compared to 0.35 for the baseline heuristic rules, with [X] recall vs [Y] for the baseline.

The dataset is small ([N] labeled answers), so treat these numbers as a promising start, not a benchmark.

Why Does Open Innovation Matter?

Open innovation was super important here for three big reasons:

Data Privacy You Can Actually Control

Post-interview debriefs contain sensitive details about private company questions, salary talk, and personal mistakes.

In local mode (Ollama + local Whisper), her raw debrief text and audio never leave her laptop and are never sent to closed API providers for training.

If she opts into Backboard, only the question, score, and top tags are stored on the remote thread, never the full raw debrief.

Because the models are open-weight, she gets to choose where that line sits.

Targeted Domain Fine-Tuning

Generic closed APIs can miss subtle conversational flaws in behavioral answers.

Fine-tuning open weights (Qwen3-8B) via Tinker allowed us to directly boost precision on her specific weakness categories like:

rambling

no_metrics

weak_closing

no_structure

No Vendor Lock-in & Free to Run Locally

The default analyzer is a heuristic engine, meaning the app works out of the box with zero API keys.

When running locally with Ollama, she gets unlimited practice drills and post-mortems for $0 in subscriptions or tokens.

Backboard and Tinker are optional upgrades, not requirements.

The Goal

PostMortem isn't trying to tell someone whether they got the interview right or wrong.

It's designed to answer a much more useful question:

"What keeps going wrong, and what can I practice before the next interview?"