Edit wiki/personal-infrastructure.md — Young Builder Resources

---
visibility: public-edit
---

# 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 [[shipping-products|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-paths|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 [[shipping-products|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.