# PHP developer — since 2008 > A PHP developer since 2008 — work shipped on Laravel, Symfony and CodeIgniter, framework-free libraries, and how I actually pick a framework. - Technologies: Laravel, Symfony, CodeIgniter, Composer, PHPUnit, Pest, Redis, MySQL, RabbitMQ - Experience: Since 2008 - Posts: 88 - Projects: 5 - Updated: 2026-09-02 - Source: https://www.muhammetsafak.com.tr/en/expertise/php/ - Language: en-US - Author: Muhammet Şafak --- ## Me in the PHP ecosystem One question sits at the centre of the work I do as a PHP developer: where will the business rule live? The framework, the directory layout and the test surface all come after that answer. Build a project in the reverse order and the rule scatters across the application — which is exactly where maintenance cost begins. What follows is what I do at application level and what I base those decisions on. Microservice boundaries, event-driven design itself and database internals I write about, with their costs, on [sade.dev](https://sade.dev). ### What I build in PHP None of them is a brochure site — I use PHP where the business rules live. - **Invoicing and payment flows** — Systems that touch the flow of money and carry the business rule inside the application. - **Asynchronous background work** — Queues, consumers and idempotent consumption; the structures that take the synchronous wait out from in front of the user. - **Framework setups** — Laravel, Symfony and CodeIgniter; on work I start from scratch and in codebases I inherit alike. All three sit on the same language, and at application level the work is done not by the framework but by where you put the business rule. - **Framework-free libraries** — MIT-licensed packages that stand on their own, from a router to a PSR-11 container. Once a library is inside someone else's project, the signature is the one thing you cannot take back. ### How I decide on a framework I do not pick a framework when I take on new work, and what sets the order is not my taste. 1. **Synchronous or asynchronous** — That one decision fixes the queue, the error contract and what happens when the same request arrives twice; it is the most expensive one to change later, and it comes before the framework. 2. **The tools the team already knows** — If nobody on the team knows Symfony, writing that product in Symfony costs more than it returns. 3. **The time given to the MVP, and the product's own needs** — The delivery date and the product's own requirements decide how much of what a framework brings ready-made I will actually use. 4. **Performance, last** — The weakest argument in that decision. When I measured it, the gap between frameworks closes as soon as the request starts doing real work. ### The order I follow in an inherited codebase Not every piece of work starts from scratch, and in inherited code the first job is not rewriting. 1. **Understand the behaviour first** — Where each rule sits, which side effect belongs to which request, how far the surface protected by tests reaches. An improvement made before those are clear risks breaking a working system invisibly. 2. **Then widen the test surface** — Put the protection in place before touching the change; every correction after that costs less. 3. **Version and dependency cleanup last** — An ordinary part of the work, held to the same measure: the cost of a change has to stay smaller than the relief it brings. ### The three surfaces I set tests on Tests are not a quality badge for me but the tool that lowers the cost of change, so they are set up as a surface from the start. - **Where the business rule is exercised directly** — The rule itself, tested without ever reaching the outside world. A rule with no test is a rule that can change quietly on the first busy day. - **Where the outer boundary is imitated** — The payment provider, the queue, a third-party service; the far side of the boundary is imitated so the test can run on its own. - **Where the flow runs end to end** — The path a request enters and a result leaves by. Only here does the case show up where every part is right on its own and the combination is wrong. ### I do not cover architecture here Microservice boundaries, event-driven design itself, database internals and cache strategy are not subjects I take on in their own right here; the place I write them is sade.dev. ## Frequently asked ### How long have you worked with PHP? Since 2008 — 18 years. 88 posts of that stretch are recorded on this site. ### Which PHP frameworks do you use? My depth is in Laravel: my first Laravel project ran on Laravel 4, and the archive carries separate migration notes from 5 through 12. But Laravel is not my only framework — I have written Symfony and CodeIgniter both on work I started from scratch and in codebases I inherited. ### Do you write PHP without a framework? Yes. I have written packages that stand on their own — from a router to a PSR-11 container — without leaning on a framework; all of them MIT-licensed on Packagist. Writing PHP without a framework is also the shortest way to learn what the framework has been doing for you. ### How do you pick a PHP framework for a project? Three parameters decide it: the time given to the MVP, the tools the developers on the team already know and the product's own requirements. Performance is usually the weakest argument in that decision — when I measured it, the gap between frameworks closes as soon as the request does real work. ### How do you start a new PHP project? Not by picking a framework. First I decide whether the work runs synchronously or asynchronously. That single decision fixes the queue, the error contract and the idempotency requirement together, which makes it the most expensive one to change later. ### Do you do architecture work as well? Yes, but not on this page. This surface stays at application level; the architectural decisions themselves — with their costs — go on sade.dev. ### How many projects used PHP? 5 of the projects recorded on this site touch the PHP side; most of what I delivered during the freelance years never made it into the portfolio.