And that's only Claude. Whatever I've put through Gemini Flash, Nano Banana, the OpenAI API, SeeDance, Wan, and whatever else sits on top of it. I haven't added those up. Honestly not sure I could since they're scattered across too many dashboards.
Anyway. Two people sitting around comparing how much they consumed. I'm not going to read too much into that, but those numbers seem high regardless.
This Was Always Going To Happen
Building has been a compulsion for me since long before any of these tools existed.
That's 20 years of shipping things, many of which nobody asked for.
The mechanism behind that is well understood and it has nothing to do with AI.
Building runs on a variable reward loop, which is the same three-part cycle you find in slot machines and video games. You anticipate that this thing might work, you do the work, and then sometimes it pays off and sometimes it doesn't.
The unpredictability is the active ingredient.
Ferster and Skinner spent something like 70,000 hours on this, mostly with pigeons, and published the results in 1957 as a 700-page book about reward schedules. It's fascinating.
Of the four schedules they mapped, the unpredictable one produced the highest response rate and turned out to be the hardest to extinguish.
Stop rewarding a pigeon that was on a predictable schedule and it gives up fairly quickly. Stop rewarding one that never knew when the food was coming and it keeps going.
The neuroscience underneath it is kinda strange too. Wolfram Schultz spent years recording from dopamine neurons and found they don't really fire for rewards at all.
They fire for the gap between what you expected and what you got. A reward you fully predicted produces almost nothing.
Which means predictability is the enemy.
If you always knew the thing would work, shipping it would feel like very little.
The uncertainty is doing the work, and if you've ever sat watching a deploy log scroll you already know how that feels.
So none of this is new, and I didn't discover anything about myself this year that wasn't already true in 2007.
The Cycle Got Shorter
What changed is how fast the loop runs.
A slot machine is worse for you than a lottery ticket, but the prize money has pretty much nothing to do with it.
You can play a slot machine again immediately. Tighten the cycle and the same reward structure that used to produce a mild hobby starts producing something else.
Going from an idea to a working thing used to take me weeks, or months, or even years in some cases. Now a lot of it takes an afternoon or maybe a few weeks.
It's the same loop with the same variable payoff, running at a completely different frequency, and the pause that used to sit in the middle of it has gone with it.
Nobody sat down and decided to do that to us. It's a side effect of the tools improving, which on balance I'm honestly glad about.
Where Mine Went
The part I find more interesting is what I've been building.
Over the past year I've replaced many of my third-party subscriptions with things I made.
- A notes app with exactly the features I wanted and none of the ones I didn't (goodbye Apple Notes)
- A simple time tracking PWA for the day job
- A dev documentation app that pulls Jira tickets and auto-updates on deploy, also for the day job
- A quick and simple invoicing tool I built for invoicing clients
- Something custom that does what I was paying Zapier to do, except it runs on my server now, and it's essentially free
None of it is clever software tbh. It all runs on my own server. The notes app in particular is the first one I've ever actually loved using, mostly because I deleted every feature I didn't want instead of learning to ignore it. And I also built what I found other notes app were missing.
Between all of them they save me roughly $225 a month, and there are a few more subscriptions I could probably take out if I got around to it.
Every one of those was likely a bad idea a few years ago. Building a notes app to dodge either Apple Notes or a $10 notes app subscription is a dumb use of a weekend, let alone three of them.
The maths only works when the build is cheap.
That's not true anymore, and I think many of us should go back and redo the math.
For over 20 years the answer to "should I just build this myself" was almost always no. Building was always possible, it just cost more of your time than the subscription cost in money.
That held true for so long it stopped being a decision and it literally became a reflex, which is exactly why it's easy to miss that it changed.
What It Actually Costs
A year ago I'd spend a few hours a month on maintenance. Dependency bumps, the occasional CVE, something breaking that I didn't notice for a week. Now that's roughly a few hours every single week.
That's about a 4x increase and it's just the cost of owning a dozen-plus things instead of renting them. It's still comfortably less than $225 a month of my time, so the trade holds (and I also enjoy the building and owning the code, which I can change at any point in time).
But it's real and recurring, and it grows with every single new thing I add.
This goes badly for plenty of people. One developer wrote about ten years of self-hosted WordPress where the updates and the broken plugins gradually ate the writing time he'd built the blog for in the first place.
He eventually gave up and moved to a hosted platform so he could get back to writing.
The other cost is harder to put a number on though.
Running a dozen live things means holding a dozen contexts and trying to remember what you decided on something you haven't opened in 5 weeks, all under a low background hum of stuff that might need attention.
That one costs me more than the hours do if I'm being honest. And it's the same attention problem I ran into with the second product years ago, except now there are 10+ more of them.
None of this is unmanageable and I'm not looking for sympathy.
The tools work, the stuff I built is stuff I use every day, and I'd make most of the same calls again.
The Cost I Didn't See Coming
One more cost took me a bit longer to work out.
When you pay for software, somebody else decides when the product is finished. The vendor picks the feature set and ships it, and you work within what they chose.
Their roadmap is a constraint on you, and most of the time you experience it as an annoyance.
I love opinionated software for all the obvious reasons. But I believe we're entering a phase of web development where users also want (and can) voice their opinions by building the exact thing they need.
If you build it yourself the constraints vanish.
Nobody says no to a feature, and no commercial reason to stop ever shows up. You can always add one more thing, and the thing you add takes an afternoon, so why wouldn't you.
I learned this the hard way with SEO Dash, which is the one recent build I partly regret.
I love the thing. I've told people I'm releasing it and I still will. But I overengineered the hell out of it, and I did it cheerfully, one afternoon at a time, because every single feature was interesting and none of them cost much.
Now I'm taking a lot of it back out before I can launch, which is a freakin' stupid position to be in. But hey, it happens.
The thing that would have saved me is the exact constraint I removed by building it myself.
Nobody was there to tell me the scope was already fine.
What The Old Constraint Was Doing
This is the same pattern I keep running into, and I wrote about a version of it recently. A limit I didn't choose was quietly doing useful work, and removing it felt like freedom right up until the bill arrived.
Build time used to be a governor on my portfolio.
It kept the number of things I owned roughly in line with the number of things I could look after, and it did that automatically, without requiring any discipline from me.
I never had to decide against building something, because it simply wasn't worth the weeks or months of effort.
That governor is gone for small tools now.
The only limit left is how much I can hold in my head, which is a far worse governor because it fails, and it fails late sometimes.
You don't find out you're over capacity until three separate things need you and you can't remember how any of them work.
Feature scope works the same way. The vendor's roadmap was a constraint that kept products finishable. Build your own and finishing becomes a decision you have to make on purpose, repeatedly, against your own enthusiasm. It's fucking hard.
How I'm Deciding Now
A few rough rules I've landed on, which seem to work without being anything as organised as a system.
- Build it if the third-party version costs real money every month and does 80% of what you need. The gap between 80% and exactly-what-you-want is where owning it truly pays off.
- Don't build it if the thing has real ongoing complexity that someone else is absorbing for you. Payments and email deliverability and anything with a compliance surface all fall in here. Those subscriptions are buying you a team rather than a feature set.
And be suspicious of your own reasoning when the thing you'd be building sits close to your actual work.
One founder set up a self-hosted Ghost blog, then reversed the decision and went to Substack, on the grounds that he'd fallen into the build trap and the point was to publish rather than to run a publishing system.
That distinction is super easy to lose.
Before starting, write down what finished looks like.
And hey, a roadmap is too much. The shortest possible description of the version you'd actually use is about right.
That written line is the constraint you no longer get for free, and it's the only thing standing between you and another SEO Dash.
And count the maintenance before you start, not after.
One tool is nothing. Twelve of them is a few hours a week, even when every individual one is trivial. Ask me how I know ;)
The Number Measures The Wrong Thing
I'll probably run similar numbers next month and I'm not planning to fix that. The tools are good and I like using them.
What I have changed is what happens before I start something.
The token counter tells me how much I built. It has nothing at all to say about how much I'm now carrying, and those two numbers have been quietly drifting apart for about a year or 2.
The compulsion was always there. All the tooling did was take away the last thing that had been keeping it in check.