Why Dependency-Light Code Outperforms Bloat

Every dependency you add to a codebase is a promise you didn’t write yourself, made by a maintainer you’ve never met, that you now have to keep. Most engineering teams accept dozens of these promises without ever reading them — then wonder, two years later, why a routine security patch takes three weeks and touches half the application.

The Real Cost Isn’t the Install

A package’s cost is not what npm install or composer require charges you at build time. It’s what it charges you every time afterward: a breaking change in a minor version bump, a maintainer who abandons the project, a transitive dependency with a CVE nobody on your team has ever heard of. We’ve inherited enough client codebases with 300+ transitive dependencies for a task that needed twelve to know the pattern by heart — the audit trail is impossible to reason about, and “just update it” becomes a multi-day investigation rather than a checkbox.

What We Actually Do Differently

At Roxonic, every new dependency has to answer one question before it gets added: could this be forty lines of code we own and understand instead? Often, the answer is yes. A date-formatting library, a debounce helper, a slug generator — these are not architecture, they’re utility functions, and utility functions you write yourself never have a supply-chain incident.

• We reserve external packages for genuinely hard problems — cryptography, PDF rendering, payment gateway SDKs — where reimplementing the wheel is a liability, not a virtue.
• We pin exact versions and review changelogs before any upgrade, rather than trusting caret ranges to silently pull in breaking changes.
• We favor the language’s standard library wherever it’s sufficient, because it has one maintainer — the language itself — and a much longer support horizon than most third-party packages.

Where This Shows Up in Practice

This discipline is visible across every system we operate, including our own products. GymCMS handles recurring billing and trainer scheduling without leaning on a general-purpose “everything” framework underneath it. The invoicing engine behind our Business Technology practice runs its GST and ledger calculations in code we can step through line by line during an audit, not inside an opaque dependency we’d have to trust blindly.

None of this is a rejection of open source — it’s a rejection of accepting complexity you haven’t priced. A codebase you can fully explain is a codebase you can fully defend, whether that’s to an auditor, a new hire reading it for the first time, or yourself eighteen months from now.

A dependency is a decision, not a shortcut — and every decision should survive being explained out loud.

If your team is carrying a dependency tree nobody fully understands anymore, that’s usually the first thing worth auditing before any new feature work begins. It’s also exactly the kind of review our Technology Consulting practice does for clients directly.