Developers love frameworks — and for good reason. They offer structure, reusable components, and a faster path to deployment. But with every new PHP framework released, we hear the same criticism:
“You’re just reinventing the wheel!”
In this article, we’ll unpack that statement. Is reinventing the wheel really such a bad thing? When does it make sense? And how do we avoid building yet another overengineered framework?
What Does “Reinventing the Wheel” Mean?
The phrase usually refers to solving a problem that already has a well-established solution — often more mature and battle-tested than anything new you could build.
In PHP, that might mean:
-
Writing your own routing engine instead of using Symfony or FastRoute
-
Creating a custom ORM instead of using Doctrine or Eloquent
-
Making your own micro-framework from scratch
But here’s the twist…
Reinventing Isn’t Always Wrong
There are valid reasons to reinvent the wheel — provided you know why you’re doing it:
1. Learning and Mastery
Building parts of a framework yourself can deepen your understanding. You’ll get to see:
-
How routers parse and dispatch URLs
-
How dependency injection containers resolve class dependencies
-
How middlewares work under the hood
2. Customization and Performance
Large frameworks solve general problems. But your app might need something specific:
-
Ultra-fast routing with zero overhead
-
A domain-specific approach that standard frameworks don’t support
-
Fine-tuned control over how services are instantiated
3. Legacy or Special Environments
Sometimes you’re working in a constrained environment:
-
No Composer
-
Limited PHP versions
-
A legacy codebase with custom conventions
When It Becomes a Problem
You know things have gone too far when:
-
You’re building your 5th custom autoloader
-
Your routing layer lacks support for HTTP methods and parameters
-
Your app breaks because your DIY ORM mishandles SQL injection
There’s a fine line between learning and wasting time on solved problems.
Best Practices if You Must Reinvent
If you’re building your own mini-framework or components, follow these tips:
Stick to Standards
Use PSR (PHP Standard Recommendations) where applicable:
-
PSR-4 for autoloading
-
PSR-7 for HTTP messages
-
PSR-11 for container interfaces
Keep It Modular
Avoid coupling your logic to your custom framework. Make it easy to swap out your homegrown router for a proven one later.
Document Everything
Others (or future you) will need to know how your code works. Don’t make your custom logic a mystery.
Know When to Stop
Use proven libraries where they save you time without sacrificing flexibility. No need to re-implement security, logging, or HTTP clients from scratch.