All services

Freelance PHP Developer

A freelance PHP developer for systems that already earn money.

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.

PHP 5.x → 820+ years of PHPZend Certified Engineerzero-downtime delivery
What I get hired for
  • Taking over existing code when the developer or agency is gone
  • PHP upgrades from 5.6, 7 or early 8 to a supported version
  • Modernization in steps that go to production one by one
  • Framework upgrades: Symfony, Laravel, Zend/Laminas
  • A test net and static analysis where the money flows
  • Reinforcing your team where PHP experience is missing
Scope & working together

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

Most portfolios show greenfield work. Your problem is the opposite.

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 into
  • The previous developer or agency is gone, and nobody knows the code.
  • The system runs on PHP 5.6, 7 or an early 8 and no longer receives security updates.
  • Every change takes longer and more often breaks something else.
  • The team is there, but PHP and legacy experience is missing at the critical spots.
  • A vendor recommends a complete rebuild, and you do not trust the recommendation.
  • An audit, a customer or your host demands a supported runtime.

Who this is for

For decision-makers whose PHP system is too important for experiments.

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.

01

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.

02

Operations must not stop.

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.

03

You want one person who takes responsibility.

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

What I work on in PHP systems

01

Taking over existing code

AssessmentRisk listDocumentation

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.

02

PHP upgrades and migrations

RectorPHPStanComposer

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.

03

Modernization without standing still

Strangler figSmall stepsRollback per step

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.

04

Framework upgrades

SymfonyLaravelZend / Laminas

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.

05

A test net and quality

PHPUnitCharacterization testsPHPStan in CI

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.

06

Performance and the limits of PHP

ProfilingCachingGo alongside PHP

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.

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

How an engagement starts

Four steps, and after the second you know where you stand. No step commits you to the next.

STEP 01

First call, 30 minutes

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.

STEP 02

Onboarding with a result

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.

STEP 03

Delivery in steps

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.

STEP 04

Handover to your team

Pairing, documentation and tests that remain. The goal is that your team continues without me, not my own extension.

The outcome

What is different afterwards

Changes become plannable again

A new requirement is an estimate, not a risk conversation. The difference lies in tests, current dependencies and documented decisions.

The knowledge no longer sits with one person

Assessment, architecture decisions and operating procedures live where your team can find them. The bus factor of your system is no longer one.

Operations ran throughout

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.

An honest limit

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

What I work with

Language
  • PHP 8.2 to 8.5
  • PHP 5.x / 7.x as the starting world
Frameworks
  • Symfony
  • Laravel
  • Zend / Laminas
  • Slim
Analysis & rewrite
  • PHPStan
  • Rector
  • Psalm
  • PHP-CS-Fixer
Testing
  • PHPUnit
  • Pest
  • Characterization tests
  • Xdebug
Data
  • MySQL
  • MariaDB
  • PostgreSQL
  • Doctrine
  • Valkey / Redis
Operations
  • Docker
  • PHP-FPM
  • Nginx
  • AWS
  • Kubernetes
Delivery
  • GitHub Actions
  • GitLab CI
  • Blue/Green
  • Canary
Method
  • Spec-driven development
  • Claude Code
  • Small commits
  • Trunk-based

Evidence

PHP and Zend Framework certified.

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.

Zertifikat: Tim Rutte, Zend Certified Engineer PHP 5.3, ausgestellt von Zend Technologies
Zend Certified Engineer – PHP 5.3
Zertifikat: Tim Rutte, Zend Certified Engineer Zend Framework, ausgestellt von Zend Technologies
Zend Certified Engineer – Zend Framework
Tim Rutte, Cloud & Software Architect

Who you are talking to

Directly with me as a freelancer. No agency in between.

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.

  • 20+years in software development
  • 50+successful projects
  • 2003working remotely since then
More about me

Working together

Working with your team or delivering independently.

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.

01Together

I work as part of your team.

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.

  • Integration into your sprints, reviews and technical decisions
  • Pairing and knowledge transfer throughout delivery
  • Code, documentation and operations remain fully with your team
02Independent

I take ownership of delivery.

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.

  • One point of contact from clarification through to delivery
  • Regular, clear progress updates without day-to-day supervision
  • A proper handover with documentation and a walkthrough

Whichever model you choose, you always know what is being built, which decisions are pending and what happens next.

Continuity

Your system remains yours.

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.

01

Access stays with you.

Code, cloud accounts, pipelines and secrets live in your systems. Operations never depend on a personal account or credentials that only I control.

02

Knowledge does not stay in my head.

Architecture decisions, operating procedures and known risks are documented where your team will find them and kept current as the work progresses.

03

Someone else can take over.

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

Common questions for a freelance PHP developer

What does a freelance PHP developer cost?

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.

Why a freelancer and not an agency?

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.

Do you take over a project whose developer is gone?

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.

Do you work inside our team or deliver independently?

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.

Which PHP versions and frameworks do you cover?

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.

Do you also build WordPress themes or make small tweaks?

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.

Do you recommend a rewrite when the code is bad?

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.

You work with AI tooling. Who reviews its code?

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.