Frameworks earn their weight
Routing, authentication, database access, validation, templating, background jobs and testing infrastructure are all solved problems. Writing them again is expensive and produces something less secure.
The argument against frameworks is usually about performance, and for typical business applications the difference is irrelevant compared with database and network time.
Match the tool to the job
| Application | Fit |
|---|---|
| Business app with users and admin | Full framework |
| API service, focused scope | Micro-framework |
| Content-driven site | CMS or full framework |
| A single scheduled script | Plain PHP is fine |
| Long-lived system with a team | Full framework, without question |
What matters in the choice
- How well maintained it is, and its release cadence
- How easily you can hire people who know it
- Documentation quality, which affects everything
- Ecosystem — what already exists for common needs
- Upgrade path between major versions
Hiring availability matters more than most technical criteria. A framework nobody in your market knows is a maintenance risk regardless of its merits.
Do not fight the framework
Most framework problems come from working against its conventions. If you find yourself repeatedly circumventing it, either the framework is wrong for the job or the approach is.
Following conventions makes the code predictable for the next developer, which is most of what maintainability means.
Keep business logic separate
Whatever framework you choose, the business rules should be in classes that do not depend on it. That makes them testable, portable and comprehensible independent of the web layer.
It also means a future framework change is a rewrite of the edges rather than of the system.