Tools I built
for Myself
A workflow gap that costs me an hour a week costs me fifty hours a year. Instead of accepting the friction — or waiting for a vendor to close it — I use Claude Code to build the missing tool. Small, focused, mine. When it’s useful to a teammate, I share it. When it’s not, it stays personal. Two examples below.
Design work sits inside a workflow
The output — the wireframe, the prototype, the recommendation — gets the attention. But the real determinant of quality is often what happens around it: how meeting notes become tasks, how a stack of session recordings becomes a synthesis, how a set of decisions becomes a shareable deliverable. Those flows either amplify the work or drain the energy that was meant to go into the work.
Before Claude Code, building a custom tool for one of those flows meant either accepting a week of engineering side-quest or living with the friction. Now it means an evening with a clear brief. That change moves the bar: if a workflow gap is real and repeats, it’s cheaper to close it than to complain about it.
A shared utility for a team
on demand, without me in the loop
A single-page web app for teammates to generate on-brand event and community thumbnails without pinging a designer or hunting for the current template.
- Problem
- A recurring team need for event and community graphics was landing in the design channel as ad-hoc requests — half a dozen a week, each a five-minute job that broke concentration on the actual project work. Teammates without design tooling were either waiting on me or shipping thumbnails that didn’t match the brand.
- What it does
- A left-hand form (title, subtitle, event type, template), a centre-panel live preview, and a right-hand image library. Pick a template, fill in copy, choose or drop an image, export a 960×540 PNG or JPEG. Two locked templates — a standard variant and an event variant — with tokenised typography, colour, and spacing.
- How CC helped
- Claude Code built the app from a written spec — the layout, the templates, the export pipeline, the deploy scaffolding for Azure App Service. The hard-won engineering decision — how to reliably export a DOM node to a raster image without font substitution — was documented in
CLAUDE.mdso the next iteration wouldn’t re-litigate it. - Impact
- Ad-hoc thumbnail requests dropped to near-zero. Teammates ship on-brand assets in a minute. The design channel gets the design questions again.
A tool for me, powered by Claude Code
Estimated weekly plan out.
A personal Jira-style tracker that turns raw meeting notes into structured tasks with time estimates, then rolls them into a weekly workload view.
- Problem
- Design work generates commitments in every meeting. Those commitments live in scattered notes, get partially transcribed into a to-do list, and by Thursday half the picture of "what am I actually on the hook for this week" has evaporated. Off-the-shelf trackers wanted me to type each task in manually — which is the friction I was trying to remove.
- What it does
- An inbox for pasting raw notes. Claude Code extracts candidate tasks — title, context, rough estimate — and drops them into a backlog. A workload view rolls the estimates into a week-by-week capacity chart. A weekly review pulls the tasks that shipped and the ones that slid. Drag-and-drop between views, local JSON persistence, no sign-in.
- How CC helped
- Claude Code is both the builder and the runtime. It built the React + Vite frontend and the Express backend. And at runtime, the extraction step shells to the local
claudeCLI with a versioned prompt to turn notes into structured tasks — no external API key, no external service. My workflow, my machine, my model. - Impact
- Notes-to-plan latency dropped from "sometime later this week" to under a minute. The weekly review became a five-minute habit instead of a Sunday-night reconstruction.
What both tools have in common
These aren’t polished commercial products. They’re targeted utilities that fill a real gap, built to a defined spec, and hardened to a level of quality that lets me — or a small group — actually use them daily. The pattern is small:
- Written before it’s built. Each tool started with a spec markdown document. Not a screen — a description of the job, the inputs, the outputs, the boundaries of what it will not do. That doc becomes the brief Claude Code executes against, and the reference I edit when the tool needs to change.
- Ship the smallest useful version. Thumbnail Generator shipped with two templates, not twelve. Task Tracker shipped with an inbox and a workload view, not eight views. Growing a tool once it’s in daily use is easy; growing a tool that isn’t in daily use is a distraction.
- Docs travel with the tool. Every tool has a
CLAUDE.mdthat captures the tool’s rules, the engineering decisions worth remembering, and the anti-patterns worth avoiding next time. When I come back six months later, Claude Code doesn’t have to re-learn the terrain.
Want to know more?
If you’re curious to hear more about how I build these — let’s talk. I’d be glad to walk you through it.