
Nye's Digital Lab is a weekly scribble on creativity in the age of AI and Distributed Systems.
This week, I'm not trying to innovate, and considering that sometimes you just need to make it work.
I still remember the developer who changed how I think about building things.
We were in the middle of a failed startup (yep, one of those stories) and while I was busy dreaming up "revolutionary features," he kept repeating this mantra:
“Make it work,
only then, make it right,
… and then, and only then…
make it rain.”
It stuck with me because it exposed something. “Innovation” as a concept, that glittering North Star every design student chases, is actually kind of a trap.

I know I am guilty of promoting unconventional creativity. Defying the norm, trying the radical, experimenting with passionate zeal. I admit it. I do that a lot.
However, I also believe that the pressure to "innovate" can actually make you worse at your job. Every company claims they want innovation. Every creative wants to be the rule-breaker, the disruptor, the one who changes everything. But somewhere between the TED talks and the Silicon Valley mythology, we’ve turned innovation into a reflex rather than a choice.
And in doing so, we’ve forgotten to ask the most important question:
Does this problem actually need a new solution,
or does it just need a working solution?

Tyranny of New
We spend so much time looking for new ideas that we forget to check if someone’s already solved our problem. I’ve watched students walk into my office announcing they want to use blockchain, or implement some AI model, or build something on whatever technology made headlines that week. Unreal Engine chaos, behavioral tree systems, data export this or that. It’s all the same.
When I ask what problem they’re solving, there’s usually a pause. They’ve arrived with a solution desperately searching for a problem to justify it.
What's the problem? And who is already working on it?
Somewhere out there, someone has probably already built 80% of what you need. Maybe it’s open source. Maybe it’s sitting in a GitHub repository with twelve stars and documentation written by someone whose first language definitely isn’t English. Maybe it won’t be perfect, but it’ll be functional, which is more than your revolutionary new approach will be six months from now when you’re still debugging the foundation.
I follow every game engine I can (not just the big names like Unreal and Unity), but O3DE, Godot, the JavaScript engines like Babylon.js and Three.js. I keep tabs on AI developments, blockchain experiments, emerging frameworks.
But I’m not doing this to innovate.
I’m doing it to avoid innovating.
I’m looking for traction, for communities, for things that work well enough that people are actually using them. Because, (and I know it sounds almost heretical in our innovation-obsessed culture) you probably don’t need to build something new.
You need to build something that works.
Make it work first. Not make it revolutionary. Not make it your magnum opus. Make it work. Then, if you’re lucky and persistent and the problem actually warrants it, you can make it right.

And only then, only after you’ve proven functionality and reliability, can you think about "making it rain."

Innovation isn’t just technically risky; it’s socially expensive.
By positioning yourself as the innovator, the person doing things differently, you automatically become the weirdo on the edge. Trust me, I'm the weirdo. That costs social capital, the professional currency we all pretend doesn’t matter...
but it absolutely does.
Watch how this plays out in any organization. The person proposing the tried-and-true solution gets nods of approval. The person suggesting something genuinely novel gets skeptical looks and requests for seventeen more justification meetings. It’s only after you’ve “made it,” after you’ve accumulated enough credibility and success that people grant you permission to be eccentric. Until then, innovation marks you as risky, unproven, potentially unreliable.
Then there’s the time cost.
Real innovation, not the buzzword kind, but the actual pioneering work, is phenomenally time-intensive. You’re not just building something; you’re building the tools to build something, then building the thing, then figuring out why it doesn’t work, then starting over. Meanwhile, your colleague who went with the established solution shipped three weeks ago and is already iterating based on user feedback.
And then there’s the danger. I actually mean literal, actual danger.
The most useful technical advice I ever received came from a guy, who lived in Hawaii, who only communicated through Signal, who paid everything through Crypto, and connected to the internet via solar powered Starlink. Paranoid as hell, not someone I’d want to grab coffee with, but absolutely brilliant at cryptography and open source development. The cypherpunk, hacker, anonymous, underbelly-in-fringe-reddits and deep-dark-forums of the internet, are exactly where innovation happens.
It's just not a safe place to be.
You won’t find that kind of uninhibited innovation inside big corporations. Legal departments, compliance requirements, and risk-averse leadership create environments where true innovation is nearly impossible. This isn’t a moral failing; it’s a practical reality. When you’re responsible to shareholders, customers, and regulators, you simply can’t afford to move fast and break things.
And this is most especially true in sectors like healthcare, education, or government where “breaking things” might mean breaking people’s lives.
You just can't do it.

The Better Way Forward
So if innovation is flawed, dangerous, and often unnecessary, what’s the alternative?
It’s disappointingly simple:
Start with problems, not solutions.
Start with users, not technologies.
When students tell me they want to build something innovative, I ask them to describe their user and their problem first. Who needs this? What specifically isn’t working for them right now? What have they tried already? These questions aren’t meant to crush dreams; they’re meant to redirect energy toward something that might actually matter.
Once you understand the problem, audit the landscape.
What solutions already exist? Where are the gaps? This research phase isn’t about stealing ideas; it’s about understanding the terrain before you decide where to plant your flag. You might discover your “innovative” idea was tried five years ago and failed for good reasons. Or you might find that the landscape has a genuine gap that nobody’s adequately addressed.
Real innovation can happen from thoroughly understanding a space and recognizing where something’s missing. You’re not innovating for innovation’s sake; you’re solving a specific problem that existing solutions can’t address.
This approach gives you permission to be boring. Use the established framework. Implement the standard protocol. Build on existing infrastructure. Because you know what’s actually impressive?
Shipping something that works.
Solving a real problem for real people. Getting users who don’t care whether your tech stack is cutting-edge because your product simply does what they need it to do.
Yes, be brave. Yes, look to the edges when you need to. Follow developer communities in your adjacent spaces. Be willing to learn from unconventional sources. But enter every project with humility about what’s already been tried and skepticism about whether your “innovative” solution is actually just inexperience talking.
Great problem solving is great problem solving, whether it’s revolutionary or boring.
And in the end, the user won’t care which it was, as long as it works.
That's it for this time. I do this every week. If you vibe to the ideas I express, consider subscribing or sharing with friends. We'll see you next time!
Nye Warburton is an educator and civic technologist from Savannah, GA. This essay was improvised with Otter.ai and then refined and edited using Claude Sonnet 4.5. For more information visit: https://nyewarburton.com
Utility Players, September 28, 2025
Yes, Start a Company: Advice for the new wave of graduation panic, May 18, 2025
The Art of Noise: Information Theory and Chaos in Art, August 16, 2025
Nye
No comments yet