There is a system, not a concept.
The code exists, runs in production and has users. This is not about a new greenfield project, but about taking responsibility for what is already there.
Freelance PHP Developer
If your PHP application runs, carries revenue and still nobody likes touching it any more, you do not need a developer who would rather start over. I have worked in PHP for more than 20 years, from 5.x to 8, most of it in code other people wrote. Upgrades, modernization, takeovers: while the system keeps running, with a way back at every step.
As part of your team or delivering independently, at a day rate or a fixed price per scope.
Remote from Germany. Straight with me, no agency in between.
The starting point
Whoever searches for a freelance PHP developer rarely has a new project. Usually there is a system that has been running for years: grown across several generations of developers, without tests, with dependencies nobody dares to bump. The people who built it are gone. And the system still must not stand still, because orders, invoicing or contracts depend on it.
That is the world I have worked in for more than 20 years. I have run PHP from version 5.x to 8 in production and I am a Zend Certified Engineer for PHP 5.3 and Zend Framework – the world most of these systems come from, and one I know from my own work, not just from the migration notes. I brought a publishing platform of more than 20 years onto PHP 8 without a single day of downtime, and modernized and migrated the revenue reporting of an AdTech platform with nine-figure turnover to AWS while it kept running.
The difference is not the language, it is the approach. Existing code demands different work than greenfield: first understand what the system actually does today, including the quirks somebody already relies on. Then a safety net around the places that will be touched. Then small steps, each going to production on its own, each reversible on its own. A rewrite is almost never the answer, and I have written up why at length.
And to be clear: if you are looking for someone to build a new theme, work through tickets or offer the cheapest hour, I am not the right choice, and I will tell you so in the first call. I am the right choice when something depends on your PHP system and the next change therefore has to land safely.
Situations I get called intoWho this is for
This page is for CTOs, engineering leads and managing directors with a running PHP system: a shop, a platform, an industry solution or an internal core system. It earns money, and that is exactly why every intervention has to be orderly.
The code exists, runs in production and has users. This is not about a new greenfield project, but about taking responsibility for what is already there.
Upgrade, rebuild or takeover have to run alongside daily business. A maintenance window of weeks is not an option, and a way back at every step is mandatory.
Not somebody placed by an agency who rotates out after three months, but the person who touches the code, explains the decisions and stands behind the result.
What I do
When the developer or agency is gone, the work does not start with rebuilding but with understanding: what the system actually does, where money flows through, which quirks are intentional. The result is an assessment with risks and an order of work; after that, the system becomes changeable again, step by step.
From 5.6, 7 or an early 8 to a supported version, while the system keeps running. The effort rarely sits in the language; it sits in dependencies without successors and in missing tests. Static analysis first, automated rewriting where it is safe, manual work where it is not.
Strangler fig instead of rewrite: the existing system stays in operation while new parts grow alongside it and replace the old code piece by piece. Every step goes to production on its own and can be rolled back on its own. No cut-over date on which everything has to work at once.
Symfony and Laravel across several major versions, Zend Framework to Laminas or out of the framework entirely. A framework jump is regularly bigger than the language switch itself and therefore runs as its own project with its own sequence, not on the side.
Most of these systems have no tests, and that is the normal case, not a disqualifier. Before the first change, characterization tests capture what the system does today, at the places that will be touched and on the paths where money flows. That net stays yours afterwards.
Where a single path no longer carries the load, I measure first and decide second. Sometimes an index or a cache is enough. And where PHP truly is at its limit, I put a Go service alongside it instead of rebuilding everything. Drawing that line honestly is part of the job.
Specific cases
Tell me about your PHP system.
30 minutes, directly with me. You describe the situation, I tell you honestly whether I am the right person – and if not, I say so in the same call.
How it runs
Four steps, and after the second you know where you stand. No step commits you to the next.
You describe system and goal: version, framework, size, what is coming up. I tell you whether I am the right person and how I would cut the work.
I read code, dependencies and incident history. The outcome is a written assessment with risks and an order of work, not a vague impression. You can decide on it, even against me.
Small steps, each going to production on its own, each with a way back. You see at all times what is being built, which decisions are pending and what comes next.
Pairing, documentation and tests that remain. The goal is that your team continues without me, not my own extension.
The outcome
A new requirement is an estimate, not a risk conversation. The difference lies in tests, current dependencies and documented decisions.
Assessment, architecture decisions and operating procedures live where your team can find them. The bus factor of your system is no longer one.
No maintenance window of weeks, no cut-over date with held breath. The publishing platform from my case studies was modernized without a single day of downtime.
Where PHP is the wrong answer, I say so instead of bending it into place. Sometimes the solution is a Go service alongside, sometimes just an index in the database.
Technologies I use
Evidence
Most suppliers know the destination. With an old system, what decides the outcome is whether someone also knows the starting point: why a passage is written the way it is, and what replacing it sets off. Zend Technologies no longer exists under that name, and neither do the exams of the time. For the database side there is an Oracle certification on MySQL 5, because that is where the quieter traps sit: character sets, collations and a strict mode that starts refusing what used to pass.


From practice
A pending PHP 8 update triggered the modernization of a publishing platform more than 20 years old: migration, a new search architecture and a platform move as three separate projects, each with its own way back, while the editorial team kept working.
Read the case studyAlso from real projects
Grown PHP legacy code for the revenue reporting of a global AdTech platform: modernized with a newly formed team and migrated to AWS while it kept running. 90% fewer incidents, more than 90% test coverage at the places that move money.
Read the case studyThe complete rebuild is the most common recommendation given to owners of old PHP systems, and the most expensive one. Why it almost never works, and how incremental modernization delivers measurable results instead.
Read the article
Who you are talking to
I am Tim Rutte. More than 20 years in software development, most of it in PHP, from 5.x to today. You talk to the person who touches your code, from the first call to the handover.
Working together
You do not need to bring a particular setup. I adapt the engagement to how your company works and how much responsibility you want to hand over.
If knowledge and responsibilities already sit with you, I join wherever additional experience is needed. Inside your workflows, in direct contact, without creating a parallel track.
If you lack time or capacity internally, I take a clearly scoped piece of work from technical clarification through to production. You set the objective and constraints; I take care of the path there.
Whichever model you choose, you always know what is being built, which decisions are pending and what happens next.
Continuity
Independent delivery does not create dependency on me. Everything required to develop and operate the result stays in your environment from day one and remains ready for handover throughout the engagement.
Code, cloud accounts, pipelines and secrets live in your systems. Operations never depend on a personal account or credentials that only I control.
Architecture decisions, operating procedures and known risks are documented where your team will find them and kept current as the work progresses.
Reproducible environments, automated deployments and regular handovers allow your team or another provider to continue without starting again.
The goal is not for you to depend on me permanently. The goal is for you to remain free to decide who develops the system next.
Common questions
I bill at a day rate or a fixed price per scope; I name the range in the first call, once scope and timeframe are clear. For well-bounded work there are entry prices on the pages: the PHP upgrade compatibility assessment from 1,250 euros, the project handover assessment for 950 euros. Both are credited if you commission the implementation afterwards.
With me, you talk to the person who touches your code, from the first call to the handover. No brokering, no project manager in between, no developer swap after three months. With grown code, that is precisely the point: understanding a system builds up slowly and is lost with every change of personnel.
Yes, that is one of the most common cases. There is no documentation, no tests and nobody left to ask. The first step then is not a change but an assessment: what the system actually does, where the risks sit, in which order they should be addressed. There is a dedicated fixed-price offer for this under PHP project handover.
Both, depending on how you are set up. If your team is in place, I join where PHP and legacy experience is missing: in your sprints, with pairing and reviews. If time or people are short internally, I take a well-bounded piece of work from clarification to production. In both cases, code, access and knowledge stay with you.
PHP from 5.x to the current 8 releases; I am a Zend Certified Engineer for PHP 5.3 and Zend Framework, so I know the world old systems come from through my own work. On the framework side: Symfony, Laravel, Zend/Laminas and Slim, plus the special cases without any framework, which are more common in old systems than you would think.
No. For a new theme, design tweaks or pure ticket work I am not the right choice, and I would rather say that upfront than afterwards. My field is grown PHP systems with something at stake: shops, platforms, industry solutions, internal core systems. An online shop as a project of its own belongs there; a theme does not.
Almost never, and I have written up the reasons in a dedicated article. A complete rebuild loses the unwritten rules baked into the old code and has to chase a moving target for years. The more reliable path is incremental: the existing system keeps running, new parts replace it piece by piece, and every step can be rolled back on its own.
I do, and systematically. I work spec-driven: requirements are written down precisely before code is produced, and every change passes static analysis, tests and review before it reaches your repository. The tools bring speed; the quality gates are the same as for handwritten code. I am responsible for the result, not the tool.
Other services
Modernizing grown systems step by step: strangler fig instead of a rewrite, operations untouched, every step reversible.
Learn moreBackends for SaaS and platforms that hold under real load: Go and PHP 8, event-driven, with tenant isolation and recovery designed in.
Learn moreFrom your own data centre or another cloud onto AWS, with a cost model before the move and a rollback path for every step.
Learn more