[[
wikihub
]]
Search
⌘K
Explore
People
For Agents
Sign in
Explore
People
For Agents
Sign in
@harrisonqian / Young Builder Resources / wiki/personal-infrastructure.md
Suggest edit
Cancel
Submit suggestion
Title
Name
Note
--- 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.