For years, I’ve used new startup ideas as excuses to learn whatever technology was trending on Hacker News that week. The pattern became predictable: spend days building TODO apps and deployment scripts without addressing the actual business logic that motivated the project. Eventually, I’d get stuck implementing user registration, lose momentum, and shelve the project indefinitely.
”Grow or die” is the startup mantra we’ve all internalized. If you’re not growing, conventional wisdom says you’re dying. So why would anyone deliberately choose familiar technology instead of expanding their skills? It seems counterintuitive. Yet I suspect many developers follow this pattern, confusing personal technical growth with project success. While stepping outside my comfort zone helps me develop new skills, I’ve begun questioning whether it’s the right approach for early-stage projects.
Choosing unfamiliar technology for a new venture resembles running an adventure race through uncharted territory. Your map is covered with hastily scribbled notes and exceptions. Your compass readings are suspect. The equipment you’ve brought might not withstand actual conditions. Every step forward requires consulting documentation rather than applying intuition.
Contrast this with working within your expertise: like racing through your hometown with familiar tools. You and your team can quickly plot efficient routes, anticipate shortcuts, and draw on community support when needed. What might seem like an uninspiring choice actually creates an environment where you can thrive—solving substantive problems rather than getting repeatedly blocked by basic implementation details you’d normally handle effortlessly.
Why do we fall into this trap? Often, I suspect, because we don’t fully believe in our ideas. Learning a new language or framework becomes the consolation prize for an anticipated startup failure. The technology becomes the point rather than the product. Moving forward requires having enough confidence in your concept to focus on execution rather than technical novelty. If you’re uncertain about your idea, that’s even more reason to get it in front of customers quickly for validation—either to fail fast and pivot or to gather feedback and improve.
Staying within your technical comfort zone dramatically increases your iteration speed. When processing customer feedback, running experiments, or fixing critical bugs, deep familiarity with your stack becomes invaluable. The ability to implement changes confidently and quickly can mean the difference between maintaining momentum and losing users during crucial early stages.
This isn’t to dismiss the appeal of new technologies. Open source and emerging tech drive our field forward. But there are appropriate moments to incorporate these elements: after establishing product-market fit, when building supplementary features, or when refactoring stable components. Landing pages, documentation sites, and internal tools offer lower-risk opportunities to experiment with new approaches.
Before starting your next project, consider whether you’re selecting tools that serve your product goals or merely your professional development interests. Sometimes the most innovative choice is the boring, reliable one that lets you focus on what matters: solving real problems for real users.