I’m a PHP developer and one point in time I didn't know what PHP framework to use and depend on so I built WebbyPHP as a single developer. I’ve made the “don’t reinvent the wheel” decision myself: back in 2020, I looked at CodeIgniter 3 and Laravel and chose to build WebbyPHP on CodeIgniter 3 instead of starting from zero. CodeIgniter 3 is still loved, and forks like PocketArc’s have kept it viable on newer PHP versions, including PHP 8.6. I maintain my layer as one developer. So I’m not against using existing code.
But I’ve also watched the PHP upgrade conversation long enough to think we’re describing the problem badly.
Accesto surveyed 203 PHP teams and found 22 reasons they avoid upgrading: no automated tests, tightly coupled monoliths, deprecated functions like mysql_*, lost institutional knowledge, PHP 8’s stricter typing turning warnings into crashes, Composer conflicts, abandoned plugins, encrypted vendor code like ionCube, zero visible ROI, “if it ain’t broke, don’t fix it,” downtime fears, fragile CI/CD, outdated server OSes. The list is long, but a lot of it comes back to one thing: teams don’t own enough of what their project depends on.
I said in a comment thread that “most developers are lazy.” I think the sharper claim is this:
Most teams under-invest in dependency ownership. They treat third-party libraries as permanent free infrastructure, and that bites them as the project grows.
That’s not just a nicer way to say the same thing. It changes the diagnosis and the fix.
“Don’t reinvent the wheel” is only half a sentence
The full sentence should be: don’t reinvent the wheel unless you know where the wheel came from, who maintains it, and how you’ll replace it when they walk away.
Using Composer is not the problem. Pulling in a well-tested package for commodity infrastructure is usually the right call. A single developer should not write an HTTP client, a router, a logger, or a mailer from scratch just to prove a point. That’s not craftsmanship; that’s wasted leverage.
The problem is when teams pull in dependencies without asking the ownership questions:
Is this package core to our product or commodity infrastructure?
Do we understand its transitive dependencies?
Is it actively maintained, or are we one abandoned release away from a fork?
If it dies, can we fix it, fork it, or replace it?
Who on the team owns that decision?
Do we have tests and CI/CD good enough to make the change safely?
Most teams don’t ask those questions. They run composer require, get speed today, and inherit a liability tomorrow. Then two years later, an upgrade turns into a week of dependency archaeology. That’s the over-reliance problem.
Laziness, skill, resources, or economics?
I still think laziness exists. Some developers avoid learning how their tools work. Some teams pull in a package for every small problem because it’s easier than thinking. That’s real.
But “lazy” is a bad root-cause label because it misses the other cases. Sometimes it’s a skill issue: the team can’t fork the package or understand the abandoned source. Sometimes it’s a resource issue: one developer can maintain a small framework layer; a product team with deadlines may not be able to fork a large abandoned dependency. And sometimes it’s a rational economic choice: ship now, accept the risk later.
The professional standard isn’t “always build your own.” That would be irresponsible. The standard is to classify dependencies:
Commodity infrastructure is to reuse it, but pin it, audit it, and know the exit cost.
Core domain logic and differentiators is to own it in-house.
Critical dependencies have an exit plan: fork, vendor, isolate, or replace.
That’s the difference between leverage and over-reliance.
What good ownership looks like
My CodeIgniter 3 decision is the kind of thing I mean. I didn’t reinvent the wheel. I chose a wheel I could own. I built WebbyPHP on a stable base, kept control of the layer that matters to my project, and maintained it as a single developer. When the ecosystem moved, forks like PocketArc’s CodeIgniter made it possible to keep going on newer PHP versions. That’s not laziness. That’s leverage with an exit plan.
WordPress is the other side of the same lesson. Most PHP projects that tried to replace it are gone. WordPress is still the most used PHP project because of the team, ecosystem, and network effects behind it and not because it wrote every line from scratch. A challenger doesn’t beat WordPress by “building from scratch” alone. It needs differentiation plus sustainable maintenance.
Same for PHP teams. You don’t win by avoiding third-party libraries. You win by not outsourcing your core competency and critical infrastructure without a lease, an audit, and an exit plan.
Before your next composer require
Ask three questions:
What happens if this package is abandoned in two years?
Can we fork it, fix it, or replace it without stopping the product?
Who owns this dependency, and where is that written down? Can it be easily upgraded?
If you can’t answer those, you’re not reusing infrastructure. You’re accumulating future upgrade blockers.
So no, most developers aren’t lazy. Most teams just haven’t treated dependencies as liabilities with a lifecycle. The ones that do upgrade faster, fork less in panic, and sleep better when a maintainer disappears.
That’s the point I was trying to make. I just needed a better sentence for it.
Top comments (0)