Originally published on LinkedIn – Read the original post
This one is harder to write than Part 1. Part 1 was about ideas. This one is about me.
I want to tell you how the Work Balance App actually started, because the truth is a little embarrassing and kind of funny.
My staff are expected to be in the office two days per week, one of which must be Wednesday. Simple rule. Except month after month I was seeing timecards that got it wrong. People would structure their week around their preferred telework days and lose track of the actual requirement. On weeks with a Monday holiday, someone would extend the long weekend by taking Tuesday and Wednesday off, then telework Thursday and Friday because those were their normal remote days. No office days that week. At all.
I explained it. I explained it again. More times than I care to count. And then one day, instead of sending yet another email, I thought: I should build an app for this.
Which, looking back, is completely absurd. No app was needed. A calendar and some basic math would have solved the problem. But frustration has a way of channeling itself into strange places, and for me it channeled itself into learning iOS development. It was mostly an inside joke with myself. I never told my team. I don’t expect anyone on my staff to ever use it. And honestly, part of what kept me going was the private laugh of knowing I was building something this elaborate to solve something this simple.
The experiment nobody knew about
I started with ChatGPT. We’d begin a session, map out a list of things to build, and start working through them. It went fine at first. But as conversations grew longer, something would shift. ChatGPT would start to lose the thread. I’d ask about the next item on our list and it would seem to have forgotten what we were doing. I’d ask it to add a standard comment header to every file in the project, it would produce a list, start working through it, and then halfway through begin losing track of which files had already been done. It would confidently suggest reopening files it had already processed. Over and over I’d have to redirect it, remind it, restart.
The bigger problem was that I started losing track of the overall project goals myself. There was no good way to maintain continuity across sessions. Every conversation was essentially starting fresh.
Then I switched to Claude.
What Claude does differently
The difference that mattered most wasn’t immediately obvious. It wasn’t the quality of a single response or the elegance of a particular piece of code, though both were better. It was how Claude managed the project over time.
Claude uses GitHub to track issues, progress, and next steps, referencing it continuously throughout our work together. Whether that was Claude’s idea or mine I honestly can’t remember, but it never occurred to me when I was working with ChatGPT. The result is that nothing gets lost across sessions.
But what really stood out was something more subtle. Claude seems to understand that its own memory has limits. It periodically and deliberately compresses and summarizes our conversations, keeping the most important context front and center so the overall project goals don’t get buried under the details of whatever we’re working on in the moment. It knows what it can’t hold onto, so it writes things down. ChatGPT never did that. It would just quietly lose the thread and keep going as if nothing had changed.
That kind of self-aware working style turns out to matter enormously when you’re building something real across many sessions. You need a collaborator who manages the project, not just the current task.
The moment it became real
Version 1.0 shipped. And I was surprised by how proud I felt.
I didn’t expect that. I’d built the thing, I’d watched it come together piece by piece, but there was something different about seeing it actually running on my phone, doing exactly what I’d imagined it would do, solving the exact problem that had frustrated me into building it in the first place.
And then I thought: I’m not done. I already have a roadmap mapped out through version 1.6, maybe 1.7. The Week Planner feature that started all of this is just the beginning. The app isn’t finished. I’m not finished.
What this really gave me
I got into technology because it felt like magic. I grew up watching Star Trek, marveling at what the library computer could do, the way it just knew things, understood questions, responded almost like a person. That sense of wonder is what pulled me toward IT in the first place. Computers were going to change everything, and I wanted to be part of that.
Thirty-six years later, after budgets and procurement cycles and compliance audits and staff meetings, it’s easy to forget that feeling. Public service has a way of grinding the wonder out of things. The work matters deeply, but the spark that got you there can quietly disappear without you noticing.
Building this app brought it back.
I have a list of app ideas. Several of them. I’ve been adding to it since the Work Balance App launched, and I’m already deep into my second project. After 36 years in IT, most of them in leadership roles where my job was to enable other people to build things, I am building things myself again.
More than that: I’m excited about what comes next. Genuinely, specifically excited. Not the general optimism you talk yourself into when a big life transition is approaching, but the particular kind of excitement that comes from having a list of things you actually want to accomplish and knowing you have the tools to accomplish them.
I’m approaching retirement at the end of 2026. I’m ready for it. But the Work Balance App is a big part of why I’m not just ready to leave something behind. I’m ready to run toward what’s next.
I’m passionate about something again. It took an app about work scheduling to remind me what that feels like.
This article is Part 2 of a three-part series, Building with Claude. Read Part 1 and Part 3