One of the best things about modern software development is that we don't have to build everything ourselves. Open-source libraries and third-party packages let us solve complex problems in minutes instead of days, allowing us to focus on what actually makes our applications unique.
That's why adding a dependency often feels like an obvious choice.
The problem is that every dependency comes with baggage.
You're not only importing code—you are also importing someone else's release cycle, security updates, breaking changes, licensing decisions, and maintenance priorities. Even the most popular packages can become abandoned or introduce changes that force you to adapt your own project.
That doesn't mean dependencies are bad. Many of them save hundreds of hours of work and have become industry standards for good reason. The key is being intentional instead of installing a package for every small problem.
Before adding a new dependency, I usually ask myself a few simple questions:
- Does it solve a significant problem?
- Is the project actively maintained?
- Could I reasonably implement this myself?
- If I needed to remove it later, how difficult would that be?
Those questions don't always lead to the same answer, but they help avoid unnecessary complexity.
While building Convertim, I've found that saying "no" to an extra dependency is sometimes the better engineering decision. A few more lines of code today can mean fewer updates, fewer compatibility issues, and less maintenance in the future.
Architecture isn't only about choosing the right technologies.
Sometimes it's also about choosing what not to add.
Top comments (0)