Right. Let’s address the elephant in the room.
For the last few months, I’ve been doing what I do best: learning things intensely, setting up elaborate systems, and producing exactly zero lines of actual application code. I’ve migrated between AI tools like a tech tourist hopping between countries, never staying long enough to unpack.
And the worst part? I’ve been enjoying it.
That’s the trap, isn’t it? Learning feels productive. Configuring feels like progress. Setting up the perfect development environment feels like you’re building something—right up until you realise the only thing you’ve built is a very expensive chair to sit in while you build nothing.
Last post, my mate hit me with the truth bomb: “Have you actually written any app code this week?”
This post is about what happened after.
🪞 The Intervention
It wasn’t just him. The signs had been everywhere—I’d just been too distracted by the next shiny thing to notice them.
My browser had 34 open tabs. Thirty-four. I counted. They included: documentation for three different agent frameworks, a comparison article titled “Which AI Coding Tool Is Best in 2025?”, two YouTube videos I’d bookmarked but never watched, and—inexplicably—a Wikipedia page about the history of BASIC that I’d somehow wandered into during a “quick research break” three days earlier.
My project folder had more config files than source files. Let that sink in.
I had a CI/CD pipeline for an app that didn’t have a single feature.
I was, and I cannot believe I’m typing this, over-engineered for a product that didn’t exist yet.
🕹️ What Would 16-Year-Old Me Do?
That’s the question that finally snapped me out of it.
Because 16-year-old me didn’t have this problem. Not because he was smarter or more disciplined—God knows he wasn’t—but because he had no choice.
When Capcom called and said “port Black Tiger to the Commodore 64,” we didn’t spend three weeks evaluating assemblers. We didn’t research whether 6502 was still the optimal instruction set or whether we should pivot to a different architecture. We didn’t set up a sophisticated toolchain and then forget to write the actual game.
We opened the editor. We started typing. We shipped.
The entire development environment was a Commodore 64, an assembler, and a stack of floppy disks that we prayed to every night like ancient relics. There was no “should we switch tools?”—there were no other tools. There was no “let me check if there’s a better framework”—there were no frameworks. There was just the blinking cursor and the deadline.
And you know what? We built an entire commercial game in about 13,000 lines of assembly. Not because we were geniuses. Because we had nowhere else to go. The constraints didn’t limit us—they aimed us.
📏 The Stupidly Simple Rule
So I made a rule. It’s so simple it’s almost insulting, and I was genuinely embarrassed to tell my mate about it because it sounds like something you’d find on a motivational poster in a dentist’s waiting room.
Here it is:
No new tools until the current feature is done.
That’s it. That’s the whole rule.
Not “no new tools ever.” Not “ignore all progress in AI forever.” Just: finish what you’re working on before you go window shopping.
If I’m building the login screen, I build the login screen. With the tools I have. Right now. Today. Even if tomorrow there’s a new framework that builds login screens while simultaneously composing jazz and filing your taxes. That framework can wait. The login screen cannot.
It’s the development equivalent of “eat what’s on your plate before you look at the dessert menu.” And like most obvious advice, it’s obvious because it works.
🧠 Why It’s Harder Than It Sounds
Simple doesn’t mean easy.
The first week was genuinely painful. I’d see an announcement—some incredible new capability, some tool that promised to cut my development time in half—and my fingers would itch. The dopamine hit of exploring something new is real, and it’s powerful, and it’s been training my brain for months.
I developed a coping mechanism. Every time I saw something shiny, I’d add it to a list called “After I Ship.” Not “never.” Just “later.” The list grew quickly. It currently has 23 items on it. Some of them probably aren’t even relevant anymore, which rather proves the point.
The shift was gradual, but it was noticeable. Day one: miserable, constantly distracted. Day three: still tempted, but writing actual code. Day seven: in a flow state I hadn’t experienced since—and I’m not being dramatic here—since the C64 days.
There’s something about not choosing that frees up an enormous amount of mental energy. When the tools are decided and the stack is frozen, all that’s left is the work. And the work, it turns out, is the fun part. It always was. I’d just forgotten because I was too busy shopping.
🔨 What Actually Happened
In the two weeks after making the rule, I built more of the actual app than I had in the previous two months. And I’m not talking about infrastructure or config or “setting up the architecture.” I’m talking about features. Screens. Logic. Things that a user would actually see and touch and use.
The login screen? Done. User onboarding flow? Done. The core daily interaction—the “micro-moment” that the whole app is built around? Designed, prototyped, and working.
Was the code perfect? Absolutely not. Was my tooling optimal? Probably not. Could I have done it 15% faster with whatever dropped on Tuesday? Maybe. But here’s the thing—and this is the bit that took me embarrassingly long to understand:
A shipped feature built with yesterday’s tools beats an unbuilt feature optimised for tomorrow’s.
Every time. Without exception.
⏪ Full Circle
The irony isn’t lost on me. I started this blog talking about the Commodore 64—a machine defined by its limitations. And here I am, forty years later, having to artificially recreate those limitations just to get anything done.
In the ’80s, constraints were imposed by hardware. In 2025, they have to be imposed by discipline. The C64 gave me no choice but to focus. Modern AI gives me every reason not to. The tools have changed beyond recognition, but the fundamental truth hasn’t: you build things by building things. Not by reading about building things. Not by setting up systems to build things. Not by optimising your workflow for building things.
You just… build things.
16-year-old me knew that instinctively. 50-something me had to learn it the hard way, through months of productive procrastination and a mate with zero patience for nonsense.
But I’m here now. The app is taking shape. The tools are frozen. The list of shiny things grows longer every day, and I ignore it with the quiet satisfaction of a man who has finally, finally, started cooking instead of reorganising the kitchen.
👀 Coming Up Next
Right—enough philosophy. Next time, I’m going to get into the actual build. What I’m making, why I’m making it, and the first real look at the app that almost died under the weight of its own toolchain.
And yes—the name. The new name. Because Zensui is dead, and what replaced it might actually be… good?
Stay tuned. Things are about to get real.