I poured hours into building an application by hand on weekends, only to end up with the foundation in place.
My favorite tool is aging
I’ve been using Microsoft Money since 1998. Microsoft killed it back in 2010. As a consolation prize, they released a free version called Money Plus Sunset Edition, and I’ve been using it ever since. A discontinued build of a discontinued product, still sitting on my machine in 2026. The funny thing is it still works. What stopped working is everything around it. Banks and brokerages keep retiring the formats it can read, so importing a statement now means converting to a format that Money can process like QFX format. Every time. Forever. The software didn’t rot. The ecosystem just moved on and left it behind.
That was the itch I wanted to scratch. I asked myself, “How hard could it be to replace it?” Not too hard, just time consuming as it turns out. I assumed I was looking at a weekend’s worth of CRUD. Instead, I found myself reverse-engineering a product that had been around for twenty-eight years, with no requirements document telling me why any of it worked the way it did.
From a distance, a personal finance app looks simple: a table of transactions and a running balance. Up close, it’s reconciliation, splits, transfers that can’t be double-counted, scheduled bills with recurrence rules that somehow predate my marriage, a two-level category hierarchy that people have very strong opinions about, and years of import quirks for different banks and brokerages. None of those things are particularly hard.
The weekend warrior
Over the Christmas break, I started building the replacement and kept at it for the rest of the break. After that, whenever I had some downtime on the weekend, I’d roll up my sleeves and try to pick up where I had left off. Eventually, I had what I remember as more than a hundred hours into it. And I had a functioning application.
A hundred hours sounds like a lot. But it’s only about two and a half working engineering weeks. Put a competent engineer on a well-defined problem full-time for two and a half weeks, and you’d expect to have something pretty usable. What I had at the end of winter was an application that worked, but it was nowhere close to being a replacement for Microsoft Money.
The basic functionality was there. It not lack of talents, I’ve been doing this long enough to know I’m not slow. It wasn’t the tools either. The stack worked well and never got in my way. And while the domain was bigger than I expected, it wasn’t some impossibly complex problem. And it certainly wasn’t a lack of hours. A hundred hours is a lot of hours.
Something was missing then I realized what it was. The Christmas break was contiguous. I had long stretches of uninterrupted time, and that’s when most of the foundation got built. It was easily the most productive stretch of the entire winter. After that, my time was fragmented into weekends and whatever spare hours I could find. Same person. Same project. Same tools. Same domain. But a very different shape of time. That’s the disruption every weekend warrior runs into…
It’s not just how much time you have. It’s how much of it you can use without having to start over.
Same person, same project, same objective, same domain. Only the shape of the time changed.
The tax
I think I know where those evening hours went. Every session started with reorienting myself. Where was I? Why did I do it this way? What is this half-finished thing? Was I in the middle of a thought when I stopped, or had I already moved on?
On a good day, that might take a few minutes. But the real cost compounds. The longer the gap between sessions, the more time it takes to get back into the work. An already short session becomes even less productive, which makes the next session harder to get started. And once I’ve invested enough time in a project, it became harder for me to walk away from it.
When getting back into a task is expensive, you naturally start gravitating toward work you can finish in one sitting. It’s not laziness. It’s a rational response. I can see it in what’s still missing from that application. The features themselves aren’t necessarily hard. They just require context. And rebuilding that context in my head every time I sit down takes time.
Six weeks later, I might not even remember which feature I was working on.
The contrast
Over this Labor Day weekend, I started again from an empty directory with one rule: no contact with the winter build. No porting. No looking at the old code. No “here’s my schema, improve it.” I didn’t want the previous attempt tainting the new one. Instead, I asked Claude to interview me and turn my answers into a specification. A couple of hours of questions and answers later, I had one. I told it to build, and went off to do other things.
I came back for a second sitting after the first build, working through the gaps in the product. Two hours of discussion, another build, then me stepping in at the decision points. Most of it was on autopilot. Over roughly twenty-four hours, Claude kept working while I was away for most of it.
Here is the interesting part. The result came from coding agents working in one uninterrupted block over a weekend. I already knew uninterrupted time matters. A team of engineers working without constant interruption can accomplish a lot. So can a weekend warrior who happens to have a large block of uninterrupted time. But even Neo needs his nap.
But my hours were still fragmented. Nothing about my life became less interrupted. What changed was that Claude didn’t need me to be present to keep moving toward what I had already decided. The distance between what a stakeholder wants and what they can actually articulate wasn’t solved by this experiment. The specifications are pretty candid about that. The intent still has to come from me.
The difference was what happened between sessions. With the winter build, I came back to half-finished code and had to reconstruct what I was thinking from memory. This time, I came back to a specification that told me what I had decided, why I had decided it, where things had stopped, and what remained. That made me rethink what a specification is for. It isn’t just documentation. Documentation is written for someone else. A good specification can be a handoff to your future self. Whether that future self is an engineer or an agent, it provides something incredibly valuable: continuity.
Write the design document first
None of this actually requires AI. We’ve been told for years to write the design document first, like a grown-up. I’ve known that for most of my career. I’ve also almost never done it for a side project.
In the age of AI, I think this has to change. Let’s be honest. Writing a specification by hand takes hours you’d rather spend building. And when you’re the only stakeholder, there’s no auditor, and nobody else is going to read it, that document rarely feels worth the effort. So the practice everyone agrees is valuable in principle loses out to the thing we actually want to do. It’s a little like TDD. Everyone agrees writing tests first has value. Yet somehow, when we’re under pressure, writing the code feels more productive.
What changed over that weekend wasn’t the value of the specification. It was the value of what the specification enabled. I’ve made a similar argument before. In It’s a Good Time to Be a Generalist, I wrote that the generalist’s historical bottleneck was execution speed, and AI is removing that bottleneck. This is a different constraint. It’s not about how fast you can execute. It’s about whether the work can survive the gaps between your sessions.
A rate problem is solved by going faster. A continuity problem is different. It’s solved when the work can keep moving without you being there, and when it leaves behind enough context that you can come back later without having to rebuild everything you already knew. That’s who I think should pay attention to this: the hobbyist with a laptop and a few hours on the weekend. The staff engineer with four hours a week to work on the migration nobody funded. The founder building something between customer calls. The person maintaining an internal tool that three teams depend on but nobody officially owns.
Basically, anyone whose attention to a project is intermittent. Specification doesn’t give them more time. It gives their time continuity.
See the final product, my finance.
