PHP pays a lot of bills and runs a lot of businesses, and a well-structured Laravel application is a genuinely pleasant thing to work in. I build backends where the domain logic lives in the domain rather than in controllers, where the database schema was designed rather than accumulated, and where the API contract is something a frontend team can rely on. I also take on the less glamorous version of this: CodeIgniter and legacy PHP applications that still work but nobody wants to touch.
Most friction between frontend and backend teams comes from contracts that change silently. I define response shapes and error formats up front, validate at the boundary, and version anything public. Being full-stack — the React frontend as well as the API behind it — means I have been on the receiving end of the alternative often enough to care.
A ten-year-old CodeIgniter application that processes real orders is not going to be rewritten in one go, whatever the plan says. The realistic path is strangling it gradually — new features in a modern Laravel service, old routes moved across one at a time, both running side by side until the old one is empty — with regression tests proving each moved route still behaves. Less dramatic, far more likely to finish.
Schema problems are the most expensive kind to fix late, because data has already accumulated in whatever shape you allowed. I would rather spend a day on the schema and the indexes at the start than a week on query optimization once the table has millions of rows.
Yes. CodeIgniter, older custom PHP, and applications where the framework is essentially whatever the previous developer invented. I audit it, get it under version control and into a sane deployment pipeline, and then we talk about modernization.
That is the usual arrangement. One person owning both sides means the API is shaped by what the frontend actually needs, and there is nobody to blame when something does not line up.
REST for straightforward resource access and public APIs. GraphQL when clients need wildly different slices of the same data — content-heavy frontends being the classic case. I will recommend one and explain why rather than defaulting to whichever is fashionable.