Building AI Tools Between Uber Rides: How I Turned Dead Time Into Development Gold
Hi, my name is Chris. I'm a former tradesperson turned rideshare driver here in Vancouver, and I've stumbled onto something pretty incredible. In the hour-and-a-half I average between rides each day, I've been teaching myself to build AI-powered applications on my phone. What I've accomplished in these scattered moments of downtime is, frankly, surprising — even to me.
I didn't leave the trades by choice. A Skil saw took most of my thumb, and that was that. Twenty-plus years as a painter, plumber, and carpenter, and one bad moment ended it. I won't pretend I wasn't bitter about it for a while. But here's the thing about being a tradesperson — even when the tools change, the problem-solving mindset doesn't. When you hit an obstacle, you don't wait for someone else to fix it. You build a solution.
That mindset has translated perfectly into software development, though I'll admit it comes with trade-offs. Whenever I encounter a roadblock in my coding journey — and trust me, I hit them regularly — I build a tool around the problem. It's like when I hit a river I can't cross, I just build a bridge. And that approach has been absolutely liberating, even if sometimes a monthly subscription might have solved the same problem more efficiently.
The Tradesperson Mindset: Problem-Solving in Code
The parallels between trades work and software development run deeper than you might expect. In carpentry, when you lack a specific jig, you build one from scrap wood. In plumbing, when you can't find the right adapter, you fabricate a temporary coupling. This kind of bricolage — using available materials to create workarounds — becomes second nature.
But software development adds layers of complexity that physical trades don't have. When a carpenter builds a jig, it either works or it doesn't. If it breaks, it's obvious. When I build a custom application, the failure modes are more insidious. An unhandled edge case might silently drop a connection, a dependency might have a vulnerability that goes unnoticed for months, and the code itself becomes a liability that demands ongoing attention.
The romance of building your own tools is real, though. There's something deeply satisfying about crafting a solution that fits your exact workflow, optimized for your specific needs rather than a product manager's assumptions about what users want. The question I constantly wrestle with is: when does this approach serve productivity, and when does it become over-engineering dressed up as problem-solving?
The First Bridge: My Custom SSH Client
My flagship creation is an iOS app I call Terms — currently in its fourth iteration. This SSH client has evolved over years of real-world use during those scattered moments between rides, and it's become perfectly tailored to my unique copy-paste, speech-to-text, AI-driven coding workflow.
The app uses biometric authentication — Face ID specifically. When I open it, the system authenticates my face and drops me directly into my VPS hosting environment, right at the command line. The technology behind Face ID is fascinating: Apple's TrueDepth camera system projects over 30,000 invisible dots to create a precise depth map of your face, using infrared imaging to work even in darkness.
The ability to sit comfortably on my phone, building tools that have real potential while constantly fixing bugs and optimizing — it's a genuine joy. I highly recommend it. And yes, there's something quietly satisfying about the fact that the same hands that used to frame walls and sweat copper pipe are now deploying Python to a Linux server from a parking lot in Vancouver.
One of my favorite features addresses a common frustration in mobile development environments. When I encounter a bug or a traceback that freezes the terminal, I simply swipe up to close the app, reopen it, let Face ID authenticate me again, and I'm immediately back at the command line, ready to continue. This seamless recovery process has saved me countless hours of frustration and keeps my momentum going during those precious between-ride coding sessions.
The technical implementation relies on storing encrypted SSH keys in the iOS Keychain, which provides hardware-backed security on devices with a Secure Enclave. The connection state management was one of the trickiest parts to get right — handling network transitions as I move between different cellular towers and WiFi hotspots throughout the city. I implemented a connection persistence layer that can detect network changes and automatically reconnect to the remote session, often so seamlessly that I don't even notice the transition happened.
Could I have achieved similar functionality with existing SSH clients? Absolutely. But those apps optimize for general use cases, while mine is laser-focused on my specific workflow. The custom keyboard shortcuts, the integration with iOS's speech-to-text for coding by voice, and the specialized clipboard management for bouncing code snippets between my phone and server — these features exist because I built them for my exact needs.
The Video-to-Audio Bridge: Solving Content Workflow Friction
The second major tool I developed emerged from a specific friction point in my content creation workflow. I needed a reliable way to transcribe videos, and while there are web services that handle this, I required something more flexible for my personal content library.
My approach was to convert videos to audio first — a much more lightweight process than uploading large video files. For years I relied on a third-party app for this, but when iOS updates would break it or I needed specific audio formats, I found myself stuck. So I built my own converter.
The underlying technology relies on FFmpeg, a powerful open-source multimedia framework that handles virtually every audio and video format ever created. Rather than reinventing decades of codec development, I built a user-friendly interface around FFmpeg's command-line tools. The app can detect the audio codec in the source video and either copy it directly or transcode it to the target format.
For transcription purposes, I typically convert to uncompressed WAV files at 16kHz sample rates — this provides excellent accuracy for speech-to-text while keeping file sizes manageable. The human voice contains most of its intelligible information below 8kHz, so a 16kHz sample rate following the Nyquist theorem captures everything needed for accurate transcription while keeping files lean.
The transcription itself runs through Whisper, which I run locally on my VPS. No audio leaves to third-party services — everything stays on infrastructure I control. Whisper excels at handling accents and technical terminology, which matters when you're dictating code and command-line instructions into a phone microphone in a parking lot.
The Economics of Gig Work Development
Let me be honest about the economics here. Those hour-and-a-half gaps between rides aren't just dead time that I'm cleverly optimizing. They're unpaid labor gaps in a gig economy that fragments work into paid driving time and unpaid waiting time. When I frame this as turning dead time into development gold, I'm participating in the hustle culture narrative that makes precarious work sound empowering.
The reality is more nuanced. Vancouver's rideshare market can be unpredictable. Sometimes I'm busy for hours straight, barely having time to grab water between rides. Other times I'm sitting in a parking lot for 45 minutes, watching the passenger request map stay stubbornly empty. Those idle moments were genuinely frustrating until I found coding.
But there's an opportunity cost worth considering. The time I spend building and maintaining these custom tools could be spent marketing my services, optimizing my driving routes, or developing entirely different income streams. The question isn't whether building these tools is impressive — it clearly demonstrates technical skill and persistence. The question is whether it's the highest-value use of limited time and cognitive resources.
My answer has evolved over time. Initially, I built tools because I encountered problems and my tradesperson instincts kicked in. Now I continue building them because the process itself has become valuable — not just because the tools solve specific problems, but because the act of building them has taught me skills that are opening new career possibilities.
The AI Integration Layer
The most recent evolution of my development work involves integrating AI capabilities across all my tools. This isn't just jumping on the AI hype train — though I'll admit the timing is fortuitous. The integration serves specific workflow needs that have emerged from months of mobile development.
My primary AI collaborator is Claude from Anthropic. When I encounter a Python traceback or a cryptic server error, I can paste it directly into a Claude conversation and get genuinely useful debugging guidance. The suggestions aren't always perfect, but they're consistently good enough to point me toward the right approach — and they've dramatically compressed the time between hitting a problem and understanding it.
The content pipeline I've built takes this further. A ten-minute voice recording made from my phone — often while parked between rides — gets transcribed locally through Whisper on my VPS, then passes through a three-stage AI process: Claude drafts the initial post, DeepSeek challenges and deepens it, then Claude synthesizes the final version. The whole thing is managed through a Telegram bot so I can approve each stage from my phone. The result goes live on my blog in fourteen languages, with translations handled by DeepSeek.
This post you're reading right now went through exactly that pipeline.
Mobile Development Constraints as Creative Catalysts
Developing serious applications on a phone sounds limiting, and in many ways it is. The screen real estate is constrained, typing long code blocks is tedious, and debugging complex issues without multiple monitors feels like trying to solve a puzzle while looking through a keyhole. But constraints often breed creativity, and mobile development has forced me to think differently about software architecture.
The constraint that proved most transformative was battery life. When your development environment is literally battery-powered and you can't always plug in while parked, every computational decision matters. This pushed me toward more efficient algorithms, better caching strategies, and a deeper understanding of when to process data locally versus remotely.
Touch interfaces forced me to rethink traditional development workflows. Instead of keyboard shortcuts and right-click context menus, everything needed to be accessible through taps, long presses, and swipe gestures. This constraint led to more thoughtful information architecture. Features that seemed essential in desktop applications revealed themselves as rarely-used edge cases when forced to justify their place in a mobile interface.
And honestly — coding on a phone with nine fingers works better than you'd think. You adapt. The trades taught me that.
The Learning Curve and Knowledge Gaps
Let me be transparent about the learning process. Teaching yourself software development while sitting in parking lots between Uber rides is not the most efficient educational approach. I've built elaborate solutions to problems that could be solved with a single line of code using the right library. I've spent days debugging issues that an experienced developer would spot immediately. I've reinvented wheels that were already spinning perfectly well.
But there's value in these inefficiencies, even if it sounds like rationalization. Building HTTP handling from scratch taught me about network protocols, error handling, and connection management in ways that using a pre-built library wouldn't have. Manual JSON parsing forced me to understand data structure design. Each inefficiency was an education I couldn't have gotten from a tutorial.
The biggest lesson I've learned is that consistency beats intensity for skill development. Coding for ninety minutes scattered across a day, maintained over months, builds more lasting knowledge than weekend coding marathons followed by weeks of inactivity. The gig work schedule, for all its instability, provides natural break points that prevent the mental fatigue that can make programming feel like drudgery.
Revenue and Sustainability
Let me address the practical question: does any of this actually make money? The honest answer is not yet, but the trajectory feels real. The tools I've built solve real problems for me, but transitioning from personal productivity tools to marketable products requires different skills and significant additional work.
The more promising revenue path might be consultancy or freelance development work. The portfolio of applications I've built demonstrates concrete skills to potential clients. The experience of building, deploying, and maintaining real applications — even personal ones — provides credibility that tutorial completions and coding bootcamp certificates can't match.
I've also started building this blog network — seventeen domains publishing in fourteen languages, all seeded from a single voice recording. If the traffic builds to a meaningful level, the referral partnerships I have in place could generate passive income. I'm being honest with you that I'm not there yet. But I'm being equally honest that the infrastructure is real, the content is genuine, and the compounding effect of consistent publishing is something I believe in.
I lost my thumb to a Skil saw. I didn't choose to leave the trades — the trades left me. But somewhere between the bitterness and the parking lots and the phone screen, I found something I didn't expect: a craft I can actually do with what I have left. The tradesperson mindset that got me into this journey continues to serve me well. Sometimes the bridge you build to cross the river becomes more valuable than whatever you thought was waiting on the other side.
Get new posts
Subscribe in your language
New posts delivered to your inbox. Unsubscribe anytime.
Receive in: