In my last post, I told you why I started building Wrench Wise: a driveway and a barn full of vehicles — a Class A motorhome, an F350, a tractor, a sailboat, three horse trailers — and not one app that understood a fleet like that. So I decided to build it myself.
And honestly? My first thought was: how hard can it be?
It’s a vehicle maintenance app. It tracks oil changes and dates. I’m a licensed engineer with 25 years in cybersecurity. I’ve got AI to write the code now. A month, tops.
It was not a month. Let me tell you how wrong I was.
On paper, I had no business being nervous.
I’m a licensed Professional Engineer. I spent 25 years in cybersecurity, much of it leading security architecture and running security organizations. And I’ve been hands-on with serious systems. I worked with other engineers on two different systems that ran the DNS for 750,000 residential and 37,000 business customers — the kind of infrastructure where an outage makes the news. I worked on a system to help protect the U.S. government from cyberattack. These weren’t toy projects.
So a little app to track when my truck needs an oil change? With AI doing the typing? Please. I’d defended the federal government from cyberattacks. This was going to be a relaxing retirement hobby.
That confidence lasted right up until I started building.
The part my confidence conveniently skipped.
Here’s the honest version, and it’s the one that matters. My craft is systems engineering and security architecture — not production software. On every one of those serious systems, I worked alongside developers whose coding skills were stronger than mine. I wrote code too — I wasn’t a bystander. But I could not have made any of it actually work without them. My job was the engineering, the architecture, and later the leadership: understanding the system, making the calls, seeing how the pieces fit and how they’d fail. The hard, production-grade coding leaned on people who were genuinely great at it.
That’s not a confession — it’s how good engineering organizations work. Specialists do what they’re best at. My value was never in out-typing the developers next to me; it was in knowing what to build, why, and where it would break. I’d just never had to carry production software across the finish line alone, because I always had people who could do that part far better than I could.
“Just oil changes and dates,” I said.
Then I actually sat down to model the thing.
Turns out “just oil changes and dates” is a fleet of vehicles measured in three completely different ways — miles, engine hours, and calendar seasons. An RV isn’t a vehicle; it’s three machines wearing a trenchcoat, each on its own schedule: the chassis and engine on mileage, the generator on hours, the house systems on the calendar. A tractor doesn’t care about your odometer — it counts hours. A horse trailer mostly needs its bearings watched and its tires replaced because rubber ages out whether you drive on it or not.
Every “simple” assumption I started with had a dozen exceptions hiding behind it. The data model alone — how do you even represent a thing that’s one asset to the owner but three maintenance schedules to the machine? — took longer than I’d budgeted for the entire app.
The wrenching was never the hard part. I can rebuild an engine. It was the thinking — and it turned out there was a mountain of it.
And the AI? The AI did not make it easy.
This is the part everyone gets wrong, so let me be precise.
AI didn’t turn me into a software engineer overnight, and it absolutely did not do all the work. An AI is a fast, capable, tireless collaborator that will also, now and then, confidently walk you straight off a cliff — write code that looks perfect and is quietly, dangerously wrong. Catching that became one of my real jobs.
What AI did do was give me back the thing I’d always relied on: a strong coding partner to turn the engineering into working software, while I did the engineering and made the calls. For the first time, I could attempt a project that previously would have required hiring a team I didn’t have. But “a partner who writes code fast” is a very different thing from “it builds the app for you.” The first is true. The second is the fantasy that sinks people.
What I was actually bringing to the table.
Here’s the realization that reshaped how I think about all of this.
For my whole career, I’d supplied the judgment, the architecture, and increasingly the understanding of what we were even trying to accomplish — while leaning on stronger coders to turn it into working software. With AI writing alongside me now, that division of labor didn’t disappear; it got sharper. When code can be generated on demand, writing it stops being the scarce, valuable thing. Understanding the problem becomes the scarce, valuable thing.
And on this problem, I wasn’t the junior partner anymore. Think about who’s actually equipped to build a maintenance app for people like me. Not necessarily the best programmer in the room. The person who’s done their own vehicle maintenance for forty years. The person who owns the motorhome that’s secretly three vehicles, the tractor measured in engine hours, the horse trailer whose bearings and floor you watch even though you barely drive it. The person who tried every existing app and knew exactly what they all got wrong.
That person was me. The AI could write the functions. It could not want what I wanted, and it could not know what a fleet owner actually needs at 7am in a cold barn. That knowledge — the domain, the judgment, the lived frustration — was the part I’d been building my whole career, and it turned out to be the part that mattered most. It’s also, as I’ll get into later in this series, the line between building a real app and generating a pile of impressive-looking junk.
So, how hard was it?
“How hard can it be” turned into nine months, nearly 4,000 commits, more than 400,000 lines of production code, and almost 12,000 automated tests — for the app I genuinely thought would take a month.
I don’t regret a minute of it. But I’d be lying if I said I saw it coming. The forty years of turning my own wrenches was worth more than any line of code I could write — and the gap between “how hard can it be” and what it actually took is most of what this series is about.
Next up: the very first tool I used to turn an idea into a working app in days — and the corner I painted myself into. 🔧