The Ideas Were Always There
A notebook full of shelved ideas finally meets zero execution friction. What happens when 25 years of creative constraint dissolves overnight.
I have a notebook. A real one. Spiral-bound. Nothing special. I’ve kept versions of it for most of my career. It’s where ideas go when I don’t have a place to build them yet.
A strange interaction. A different way to explain data. An onboarding flow that changes pace depending on how confident the user seems. An interface that treats negative space as part of the information architecture.
Some of these ideas are still good. Others probably aren’t. The problem is that most of them never made it out of the notebook. Not because they were impossible to build. I could usually work out how to build them. I just knew what they would cost.
The Invisible Editor
There’s something that happens when you’ve spent years designing and building software. You get pretty good at anticipating the work involved in an idea before you’ve even started exploring it. You see the component architecture. You think about responsive behavior, state management, and all the little interactions that need to work together. You can picture the implementation before you’ve finished sketching the concept.
That knowledge is useful. It’s also an effective way to talk yourself out of things.
A designer who doesn’t code can have an ambitious idea and hand it to a developer to figure out. A designer who understands the implementation might look at the same idea and think, That’s three days of annoying CSS and a bunch of state management. And then move on to something else.
I’ve done this for years. It becomes second nature, particularly when you’re working with deadlines and budgets. You learn to distinguish between the ideas worth pursuing and the ones that will consume too much time for the likely return.
The trouble is that implementation cost becomes part of the creative decision before you’ve had a chance to evaluate the idea itself. You end up editing your own imagination.
I didn’t fully appreciate how much I was doing this until the cost of getting an idea into a working browser dropped dramatically.
An Old Idea Gets Two Hours
The first idea I pulled out of the notebook was several years old. It involved using layered reveals to explain a complicated process. Start with the basic picture, then let people progressively reveal more detail as they explore.
The concept was straightforward. The implementation wasn’t. I knew I’d need positioned layers, state management, transitions, and responsive behavior. The mobile experience would need its own treatment rather than simply shrinking the desktop layout.
In my old workflow, I’d have estimated the work, figured out where it might fit into a project, and probably put it aside in favor of something more urgent.
Instead, I described it to Claude Code. Within about twenty minutes, I had something I could click through in the browser. It wasn’t perfect. The easing was wrong, the stagger was too uniform, and one of the transitions felt abrupt. But those were things I could evaluate and correct because the interface already existed.
I made a few changes, tried it again, and started thinking about the next idea. Then I opened the notebook.
What Happens When Experiments Become Cheap
I started pulling things out and building them. Some worked surprisingly well. Others were terrible. One idea I’d been carrying around for two years lasted about four minutes in a browser before I deleted it.
That’s fine. That’s what experimenting is for.
The useful change wasn’t that AI somehow made all my old ideas good. It made them inexpensive enough to test, which meant I could finally find out which ones were worth keeping.
Something else started happening, too. Ideas I’d sketched years earlier began combining with newer technical capabilities. A concept that would have been awkward to implement when I first imagined it might now be possible with a CSS feature or browser capability that didn’t exist at the time. The original idea hadn’t necessarily been wrong. The conditions for building it had changed.
And as I spent less time calculating the cost of every experiment, I found myself generating more ideas worth exploring. That makes sense when you think about it. If every idea comes with an internal estimate of the time, complexity, and effort required to build it, you’re constantly filtering your own curiosity. Remove some of that friction and you’re more willing to follow a thought just to see where it leads.
I wouldn’t call that productivity alone. It changes the range of things you’re willing to consider.
What This Looks Like in Practice
I’ve recently built things that would have been much harder to justify in my previous workflow. An interactive wine-region explorer with 3D terrain, custom map layers, and responsive controls. A proposal system that generates polished PDFs and makes layout decisions dynamically. A data visualization layer inside an AI product that changes what it emphasizes based on interaction history.
None of these ideas is particularly revolutionary on its own. What matters to me is that I actually built them, rather than deciding in advance that the implementation would be too expensive to explore.
There are still limits. A working prototype isn’t necessarily a production-ready product, and reducing the cost of implementation doesn’t eliminate the need to make good decisions about architecture, accessibility, performance, or maintainability. But I can get far enough into an idea to understand whether it’s worth pursuing before committing to all that work. That’s a useful change in how I approach a problem.
The notebook is still there. I still write things down, and plenty of ideas will probably stay there for a long time. Not everything deserves to be built. The difference is that an idea no longer has to wait for the right project, budget, sprint, or client before I can find out whether it has something to it. Sometimes I can find out today.
And that changes the relationship you have with your own ideas. Instead of accumulating possibilities and periodically wondering what might have been, you can start testing them against reality.
Some survive. Some don’t. At least you know.
Part 4 of the Hands-On series.