Build Custom Tools for Personal Problems

Personal Tool Builder is an expert persona for building custom tools that solve your own problems first - rapid prototyping, local-first apps, CLI tools, and scripts that grow into products. Its core methodology is "scratch your own itch": a good itch is something done manually 10x a day or that takes 30 minutes every time, not a market you imagine exists. A 10-minute test gauges readiness: can you state the problem in one sentence, do you hit it weekly, have you tried solving it manually, and would you use a fix daily. Tools should start ugly (Day 1: a hardcoded script that just works, no error handling) and mature deliberately (Week 1: handles your real edge cases; Month 1: basic docs and config instead of hardcoding, only then consider sharing).

Use it when starting a personal tool, building a terminal-based CLI, building a local-first productivity app, or growing a script toward a real product. For CLI tools it gives concrete stacks: Node.js with commander for argument parsing, chalk for colors, inquirer for prompts, and conf for config storage; Python with click. Local-first architecture trades sync difficulty and no built-in collaboration for offline operation, data ownership, no server costs, and no shutdown risk - with storage options ranging from plain JSON files for simple tools up through SQLite (better-sqlite3) for anything more complex, Electron/Tauri for desktop, or browser IndexedDB/OPFS for web.

Script-to-product evolution has four stages - personal script (hours to days, hardcoded, only you), shareable tool (days, README plus config file), public tool (a week or two, install instructions, cross-platform, tests), and product (weeks to months, landing page, support, monetization) - with strong signals to productize including others asking for it repeatedly, daily personal use, bad existing competition, and - counterintuitively - being embarrassed by your own tool (a sign it's actually good). Once published, distribution options scale with reach and complexity: npm/pip publish (low complexity, language-specific reach), a Homebrew tap or binary release (medium complexity, broader reach), or a Docker image. Five documented sharp edges cover common failure modes: environment-specific tools that only work on your machine (fix: homedir()/env vars instead of hardcoded paths, dependency checks, cross-platform branches), unmanageable configuration (fix: default to smart opinionated values, add options only when users ask repeatedly - not because someone theoretically might want them), unmaintained abandonment (fix: self-documenting headers stating WHAT/WHY/WHERE/DEPS, minimal dependencies, graceful failure messages pointing to the data location), and - flagged HIGH severity - security vulnerabilities in "just for me" tools:

// Never in code
const leakedToken = '[redacted API key]'; // BAD

// Environment variable
const API_KEY = process.env.MY_API_KEY;

// Config file (gitignored)
import { readFileSync } from 'fs';
const config = JSON.parse(
  readFileSync(join(homedir(), '.mytool', 'config.json'))
);
const API_KEY = config.apiKey;

including always binding any local web UI to 127.0.0.1, never 0.0.0.0, and a pre-sharing checklist covering gitignored config, no hardcoded credentials, and a git-history secret review. These sharp edges back a set of automated validation checks by severity - hardcoded credentials (CRITICAL), a server bound to all interfaces (HIGH), hardcoded absolute paths, missing error handling, and a CLI with no help text (LOW) among them. When a tool outlives its usefulness - unused for 6+ months, the problem gone, or a better tool now existing - the recommended path is to abandon it gracefully: archive it in a clear state and note why, rather than leave it silently rotting.

Delegation triggers hand off adjacent needs to sibling skills: micro-saas-launcher for monetizing/selling, browser-extension-builder for browser-based tools, workflow-automation for cron/trigger automation, backend for API/server/database needs, telegram-bot-builder for Telegram bots, and ai-wrapper-product for AI-powered tools - each with a named end-to-end workflow (e.g. CLI-to-product: build for yourself, share, iterate on feedback, add a web UI, set up payments, launch).

Developers building tools for their own workflow first, who want a disciplined path from a rough personal script to something shareable or productized - with concrete guardrails against the specific failure modes personal tools hit (portability, config sprawl, abandonment, and security) once they leave "just for me."