Why teams still pick CodeIgniter and when they should not
A small framework is a feature
CodeIgniter asks for very little. There is no build step to learn, no long list of required services and no steep convention to memorize before a page renders. A request comes in through one front controller, a route points to a controller method, the method talks to a model and returns a view. A new developer can trace that path in an afternoon. For an operations dashboard, a quoting tool or a membership back office, that directness keeps the cost of ownership low for years.
Where CodeIgniter 3 stands now
CodeIgniter 3 is in maintenance. It receives fixes, while new features go into CodeIgniter 4. That does not make a working CodeIgniter 3 application unsafe by itself. What matters is the layer underneath: the PHP release it runs on, the way database queries were written, how sessions and passwords are handled, and whether third-party libraries copied into the project years ago are still looked after. We check those four things first, because they decide whether you can stay put or need to plan a move. Our CodeIgniter 3 support page explains what staying put involves.
What CodeIgniter 4 changed
CodeIgniter 4 is a new framework that kept the name and the philosophy. It uses namespaces and Composer, keeps the web root in a separate public folder, reads settings from an environment file, and ships with a command line tool, migrations, filters and a testing layer. It is the right base for anything we start today. It is also the reason a move from 3 to 4 is a port and never a one-click update, which we cover on the CodeIgniter 3 to 4 upgrade page.
When we suggest something else
We like CodeIgniter, and we still talk clients out of it sometimes. If your roadmap includes heavy background processing, subscription billing, multi-tenant accounts or a large team working in parallel, Laravel gives you more of that out of the box and a wider pool of packages. If the application is a content site with a few forms, WordPress will probably cost less. We would rather tell you that before the quote than after the build.
How we handle code we did not write
Most CodeIgniter work starts with an application another team wrote. Before we change anything we get it running on a staging server, put it under version control if it is not already, and read the parts that carry money or personal data. You get a short written assessment: what is sound, what is risky, and what we would fix first. Only then do we estimate the work you asked for.