When Time Is Short, Choose Boring Tech
The case against bleeding-edge frameworks and tech gunslinging when delivery speed matters more than novelty.
I’ve got an idea I want to try—and I want to monetize it fast.
As I started scaffolding the architecture, I reached that familiar crossroad: choosing the tech stack.
It’s my idea, my project. I could use whatever technology I like, from the most mainstream framework to some quirky self-made library.
So what should I choose, and why?
Let’s go back to the premise:
I want to monetize it fast.
This scenario might sound familiar. Maybe it’s your own side project. Maybe it’s a custom solution for a client. Either way, if time is critical, there’s only one direction that makes real sense:
Go with what you know best.
If you need to deliver, maintain, and possibly expand fast, there’s no room for tech experiments.
Choosing a technology stack you're already familiar with lets you focus on what actually matters: building something that works and satisfies end users.
But what if you want to experiment?
There’s no doubt: doing a real project with an unfamiliar technology is one of the best ways to learn.
But—there’s always a “but”—you’ll spend a lot of time learning without making tangible progress on your project. That time loss can be frustrating, especially when delivery speed is a goal. You'll hit bumps, burn hours, and get blocked by things that have nothing to do with your core idea.
That’s fine when time isn’t a factor. But when it is? That learning curve becomes a liability.
That’s why I also brought up the example of custom work for a client. There’s no client on Earth without time constraints. If you want to reduce stress and risk, using a familiar stack is the most reliable path.
Every project already has enough uncertainty. Adding more on the technical side can turn friction into failure.
Real-world vs. tutorials
Learning is great—but we all know real-world products have little in common with step-by-step tutorials. When you're on your own, you face a million edge cases and need to adapt well-known concepts to your specific use case. That takes time, even if you’re an experienced engineer.
A word on bleeding-edge tech
Most of us in tech love innovation. There’s always a new language, framework, or tool dropping every week.
So what happens if you pick something ultra-new for your project?
You’ll probably run into incomplete documentation and missing features.
Sure, lack of docs can sometimes be solved by diving into the source code. But missing features? That’s another story. You might need to build significant parts yourself—components that the framework should handle. And those components will need to be solid: engineered properly, tested thoroughly, and ready for production.
Remember, we want to go live fast—and that means a certain level of maturity and stability is non-negotiable.
Personal example
Contributing to new tech is exciting, no doubt. I remember back when I was deep into JavaScript, I contributed to a little-known framework called Vue.js. It was fun, I learned a lot, and I still remember what I did.
At the same time, at work, I was building production apps—and guess what I used there? Angular 2.
Well-established. Fairly complete. Backed by a large community.
Learning and making money rarely move at the same pace.
Flashy vs. reliable
If you’ve got the luxury of time and money to invest two or three times longer in your project, more power to you. But for me, the reliability of a production tool is way more important than the flashiness of the tech stack.
In over 15 years of career, I don’t recall a single end user asking me which technology stack I used.
Sure, there are always a few nerdy exceptions who care about this stuff—but let’s be honest, they’re not the ones paying the bills.
As a lead architect, I’ve had countless conversations with enthusiastic junior devs or tech gunslingers about why we aren’t using the “next big thing.” And often, the reason is simple: it’s too new.
Statistically, fewer people know it. The community support isn’t there yet. Documentation might be spotty. Libraries might not exist. And when you need help, you’ll be mostly on your own.
Will AI change this?
That said, I’m genuinely curious to see how this dynamic evolves with the rise of AI.
Right now, most AI models have a knowledge cutoff. Even when they can access the internet, their real strength still depends on the quality and volume of documentation available. The newer the tech, the less training data there is—so AI help is limited. I expect this will shift quickly, but today, it’s still a factor.
Articles I enjoyed this week
