When Not To Use A Framework

A framework is not mandatory for every PHP program. Small scripts, focused command-line tools, constrained integrations, and simple libraries may be clearer with the language, standard library, and a few selected packages.

Start With Responsibilities

A command-line tool that reads a CSV file, validates rows, and writes a report may not need a framework. It can still use Composer, autoloading, tests, clear error handling, and a suitable CSV parser.

A public web application has different responsibilities. Authentication, authorization, CSRF protection, validation, routing, error handling, database migrations, logging, and test support create integration work. Rebuilding these badly costs more than learning an established framework.

Keep Small Projects Structured

Avoid treating framework-free as structure-free. A small project can still separate its entry point from application code:

composer.json
bin/import-orders
src/
tests/

Install selected packages for problems they solve well. Keep construction near the application entry point. Write tests around the core behaviour.

Revisit The Decision

Requirements change. A small internal tool may gain HTTP endpoints, users, scheduled work, and persistent data. Reconsider the architecture when the team spends increasing time assembling infrastructure or maintaining custom solutions to standard problems.

The useful question is not whether frameworks are good or bad. Ask which responsibilities the project has, which are likely to appear next, and who will maintain the integration work.