personal infrastructure

building your own tools teaches you more than any course. every tool you build for yourself solves a real problem — which means you're learning under real constraints, not artificial ones. and the tools you build often become the most interesting things in your portfolio, because they reveal how you think.

the principle

if something annoys you, build a tool to fix it.

not "file a feature request." not "google for an app." build it. the tool will probably be rough and specific to your workflow — and that's fine. the point isn't to build a polished product (though some of these do become real products). the point is to develop the instinct that you can bend your environment to your will.

tools I built for myself

each of these started as "this is annoying, let me fix it" and turned into a real learning experience:

ContextFlow

• keyboard shortcut triggers ChromaDB RAG search, injects relevant context into your prompt
• the problem: I kept re-explaining the same context to AI tools. now a hotkey pulls in relevant docs automatically.
• what I learned: RAG pipelines, ChromaDB vector search, keyboard shortcut hooks, prompt engineering at a systems level

ConvoFlow

• real-time AI conversation orchestrator
• Deepgram for speech-to-text, Gemini for AI responses, all in real-time
• the problem: I wanted a flowing conversation with an AI, not a chat interface
• what I learned: real-time audio processing, streaming APIs, orchestrating multiple services

VoiceFlow

• macOS dictation app (Swift, AssemblyAI)
• the problem: macOS built-in dictation wasn't good enough
• what I learned: Swift development, macOS app architecture, AssemblyAI's API

Sides

• AI-powered decision comparison tool
• Next.js + Gemini
• the problem: I make too many decisions by gut feel. wanted a structured way to compare options.
• what I learned: building with Gemini's API, decision-framework UX design

wifi-client

• auto-join networks, fill captive portals, manage a credential vault
• the problem: I move between cafes constantly and dealing with captive portals is soul-crushing
• what I learned: network APIs on macOS, web automation for captive portals, credential management

checklist-speedrun

• keyboard-driven checklist runner with Google Sheets logging
• the problem: morning routines kept slipping. wanted to gamify completing them with speed metrics.
• what I learned: Google Sheets API, keyboard-driven UI design, personal data tracking

tmux-assistant-resurrect

• custom tmux session management
• the problem: losing tmux sessions meant losing work context
• what I learned: tmux scripting, session state management

local-deep-research

• local deep research infrastructure
• the problem: wanted research capabilities that run locally without sending data to external services
• what I learned: local LLM orchestration, research workflow automation

why this matters

learning by necessity

every tool above taught me a technology I wouldn't have learned from a tutorial, because the motivation was different. tutorials give you artificial problems with known solutions. personal tools give you real problems where you have to figure out the solution — and the scope, and the UX, and whether it's even worth building.

this is the purest form of learning by building. you can't be bored working on your own problems.

portfolio signal

personal tools tell a story about how you think. when someone sees your GitHub and finds a collection of tools you built to solve your own problems, they learn:

• you notice inefficiencies (product sense)
• you can build solutions (engineering skill)
• you follow through on ideas (execution ability)
• you have taste (design sense)

this is a stronger signal than any tutorial project or coding challenge.

the product pipeline

many real products started as personal tools:

• Dropbox started because Drew Houston kept forgetting his USB drive
• Slack started as an internal tool at a gaming company
• Rails started as the framework DHH built for Basecamp

if your personal tool solves a problem other people have, it can become a product. WorkableCafes started because I personally wanted to know which cafes had good wifi. wifi-client started because captive portals annoyed me.

how to start

1. keep a friction log. for one week, write down every time something in your workflow annoys you. "I wish X existed" or "why is Y so hard" or "I do Z every day and it takes too long."

2. pick the most annoying one. the more annoying, the more motivated you'll be to finish.

3. build the simplest possible version. a bash script counts. a single-file Python script counts. don't architect a full app — solve the problem.

4. use it. if you don't use your own tool, it wasn't solving a real problem. iterate based on your own experience.

5. share it. put it on GitHub. write a README. someone else might have the same problem — and now you have an open-source project.

the tools you build for yourself are the most honest representation of you as a builder. they show what you care about, what you're capable of, and how you think about problems. see tools-stack for the technologies I use across all of these.