The calculator I built and barely use
I built a French Press Calculator a while back because doing ratio math before caffeine felt like a problem worth solving. It works. It does exactly what I wanted it to do. And I use it maybe twice a week (generously) because most mornings I just eyeball it or have already set the drip the night before.
Which is the whole thing, really. Building the calculator and actually making it part of my routine are two completely different projects. The first one was fun. The second one is boring and ongoing and arguably the only one that matters. I only finished the first one.
I do this constantly. I have a folder of project ideas that is embarrassingly longer than my folder of shipped projects, and within the shipped folder, “things I actually use consistently” is a much shorter list. I know this about myself. I still open new tabs.
This isn’t just a side project problem
I’ve watched this exact pattern play out at every company I’ve worked at. The exciting part is always the evaluation, the implementation, the launch. Milestones happen. Slides get made. Someone gets credit. Then six months later the data’s a mess, half the team found workarounds, and leadership is asking whether we should evaluate a new tool. To solve a problem the current one handles fine, if anyone had spent time maintaining it instead of chasing the next shiny build.
I wrote about discovering a rogue email platform at a previous company. The team that built it wasn’t doing anything wrong. They needed a tool, found one, and made it work. The problem wasn’t the building. The problem was that nobody maintained it. Nobody documented it. Nobody audited whether it still made sense three years later. By the time I found it, the shared login had been passed through four people and the segment logic lived entirely in one person’s head.
That’s what happens when you only fund the build and treat everything after launch as someone else’s problem.
Why the boring part loses
I think the reason is pretty simple: building has a finish line and maintenance doesn’t. You can ship a thing. You cannot ship upkeep. It just keeps going, nobody notices when it’s working, and everyone notices when it breaks.
There’s also a recognition problem. Nobody gets promoted for “kept the thing running.” There’s no conference talk called “I Didn’t Break Anything for 18 Months.” The incentive structure at most companies rewards launches, not longevity. So people optimize for launches. And then they’re surprised when the thing they launched falls apart.
It’s the same reason overengineering is so seductive. Building the architecture is the interesting part. Migrating the data, writing the docs, training the team, answering the same question six times — that’s the part that actually determines whether anyone uses it. But it’s not fun. Nobody’s staying late because they’re excited to update a runbook.
What actually helps
I’ve gotten better at this at work, mostly by tricking myself. Documentation ships with the feature, not after. Audits get scheduled on the calendar instead of triggered by something catching fire. Quarterly reviews include “what are we maintaining and is it still working” alongside “what are we building next.” It doesn’t make the boring stuff interesting, but it makes it expected, and expected is close enough to tolerable.
The teams I’ve seen do this well treat maintenance like a first-class deliverable. They budget time for it. They celebrate it, or at least acknowledge it exists. They don’t wait for something to break before they look at it. It’s not glamorous. But the platforms those teams run tend to actually work, which is more than I can say for a lot of shiny new builds I’ve seen.
Personal projects are a different story. Nobody is holding me accountable for whether I use my own coffee calculator. There’s no quarterly review where someone asks why my side project adoption metrics are flat. It’s just me, noticing that I built a thing and then wandered off, again.
The uncomfortable truth
The boring part is where the value actually lives. The build gets you from zero to one. The maintenance is everything after that. And “everything after that” is where your users are, where your data lives, where the thing either works or quietly rots.
I don’t have a neat takeaway here. I haven’t cracked the code on making maintenance fun. I’ve just gotten slightly less bad at not skipping it entirely.
That’s the whole update. Now if you’ll excuse me, I have a calculator I should probably go use.