Every dependency you add is a bet. Not a technical bet. A trust bet. You are betting that the library author stays interested, that the vendor doesn't get breached, that the framework you built on doesn't become the next cautionary tale. Most founders never think of it that way. They think of dependencies as free leverage. They are not free. They are deferred liability.
The Accumulation Problem Nobody Names
Here is the pattern we keep watching. A team ships a product. It works. Growth happens. Along the way, someone adds a library because it's easier than reading the MDN docs. Someone adds a vendor because the integration looks slick. Someone adds a third-party auth layer because "security is hard." Nobody stops to total the tab. Then, one day, a breach notification lands in customer inboxes, and the source turns out to be a vendor the company trusted with its customer database but never thought twice about.
That is exactly what happened to Framework, the modular laptop company whose customer data was accessed through a compromised third-party accounting vendor. Framework didn't get hacked. Their vendor did. The distinction felt important to Framework's engineering team, probably. It felt like nothing to the customers whose information walked out the door.
At the same time, SIM swapping attacks are gutting people who thought their phone number was an anchor. It isn't. The phone carrier is a dependency too. You trusted it to hold your identity. They trusted an underpaid support rep not to be socially engineered. That chain of delegated trust is the entire attack surface.
The JavaScript Version of the Same Problem
On the frontend, the same logic applies and almost nobody sees it. Smashing Magazine's breakdown of Baseline makes a point that should embarrass most engineering teams: the browser now handles huge swaths of what teams have been shipping JavaScript for. Dialog elements, scroll-driven animations, container queries, native form validation. The platform caught up. But the dependencies didn't leave. They just sat there, in the bundle, being fetched by every user, adding surface area for supply-chain attacks, slowing down the experience, and adding maintenance overhead with every upstream version bump.
Every npm package is a trust relationship. It has an author, a maintainer, probably some transitive dependencies with their own authors and maintainers. You are not just shipping code. You are shipping a web of human decisions you didn't make, didn't review, and probably can't audit. When the browser can do the job natively, shipping the library anyway isn't "safe," it's the opposite. It's importing risk for free.
The Scientific Computing Mirror
There's a version of this playing out in places you'd never expect to look. A lobste.rs thread on software literacy in scientific research describes what happens when a grad student builds critical tooling without engineering fundamentals. Two hundred gigabytes of simulation output split across tens of thousands of text files. A processing job that takes an hour when it could take seconds. Nobody told the grad student any of this was wrong. They were solving the problem in front of them with the tools they understood, and the result was a system nobody else could safely touch.
Sound familiar? That is every startup's internal tooling by year three. A Zapier workflow someone built at 2am that now handles real money. A Google Sheet that is technically a database. A script a contractor wrote that only one person understands and that person left in March. The same pattern: real work done with the tools at hand, trust accumulated without accounting, fragility hidden inside something that looks like it works.
The AI Tutor Tells You Something About Knowing When to Step Back
Here's an angle from a direction you'd never expect. Research on AI tutoring systems is focused on a surprisingly human problem: knowing when to help and when to hold back. An AI tutor that jumps in too fast robs the student of the productive struggle. An AI tutor that stays silent too long lets the student flail. The skill is in the calibration. The same calibration most founders never apply to their stack. Every dependency you reach for is the tutor jumping in. Sometimes that's right. But if you never ask "does the browser actually handle this now? does our own code do this already? does this vendor know anything about our customers that we'd regret them losing?" you are outsourcing judgment you should be keeping.
The discipline of holding back, of choosing not to add the library, not to hand over the data, not to patch the workflow with a third-party bandage, that discipline compounds. Every dependency you don't take on is one attack vector that doesn't exist, one vendor breach that can't reach your customers, one less maintainer's judgment call baked into your production system.
What This Means If You're Building Right Now
We are not telling you to write everything from scratch. That is how you end up with a worse version of something that already exists and a 12-month delay. But we are telling you to get honest about what you owe your trust to.
Run the audit. Sit down with your team and list every third party that touches customer data. Every one. The payment processor you know about, but also the support ticketing tool, the CRM, the accounting platform, the email delivery provider, the analytics package. Now ask: what happens if any one of these is breached? What data walks? What's your notification obligation? What's your customer's exposure?
Run the same audit on your JavaScript bundle. Use the Baseline signal as a forcing function. If the browser can do it natively and the browser support is solid, remove the library. Fewer requests, smaller bundle, one less upstream author whose judgment you're importing. A smaller attack surface is a smaller trust surface.
And run the audit on your internal tooling. Find the thing that only one person understands. Document it. Or replace it. Because "it works" is not the same as "it's safe," and in a business that actually matters to you, that distinction is the difference between a bad week and a catastrophic one.
The Real Question
Most of the technical decisions that blow up companies were reasonable at the time. Nobody hand-delivers their customer database to an attacker. Nobody ships a vulnerable dependency on purpose. The harm comes from the gap between "we trusted this" and "we accounted for that trust." The gap grows invisibly. Every vendor, every library, every workflow tool someone wires up without a review adds to it. The stack gets bigger. The trust surface grows. And at some point the blast radius is bigger than the business can absorb.
The founders who don't get caught in this are not the ones who trust nothing. They are the ones who trust deliberately. They know what they handed over to whom and why, and they review it often enough to catch drift before drift becomes damage.
Your stack isn't just an engineering decision. It's a promise to your customers about what happens to their information, their trust, their relationship with you. Audit it like one.