PHP development and modernisation

Do you need something in PHP that no ready-made plugin solves?

I have written PHP for 19 years. I build custom plugins and server-side logic, and rescue legacy code that keeps a business stuck on an unsupported version.

PHP runs most of the web that businesses actually depend on, and it has changed a great deal in recent years. Modern PHP 8.3 brings types, exceptions, attributes, a fast runtime and solid static analysis tooling. The distance from code written a decade ago is large, yet many companies still operate applications that never made that journey. The consequences arrive gradually: hosting drops support for the old version, security fixes end, every change takes longer and nobody dares touch the part that still works. This is where most of my work happens. Either I write new functionality to fit the business, or I bring existing code into a state where it can be developed safely again.

I am a freelance developer based in Poprad. I work remote-first and you talk to me directly rather than through a project layer. Over 19 years I have written e-shops, event registration systems for conference organisers, subscription portals, invoicing solutions, B2B portals and a long list of custom WordPress plugins in PHP. The rate is €40 per hour including VAT. A smaller plugin or a behaviour change is typically 4 to 12 hours, while a larger module or the rescue of an older application runs into tens of hours. I only estimate after looking at the code, because an honest number for someone else's application requires the project open in front of me.

01

Custom plugins and modules

When an off-the-shelf plugin does eighty percent of what you need, the remaining twenty percent usually costs more than a purpose-built solution. I write plugins that do exactly one thing well: a custom content type, pricing calculated by your rules, a specific form with a connection behind it, altered cart behaviour or an administration screen shaped for the people who use it daily. Custom code carries no ballast built for thousands of other sites, brings no marketing dashboard of its own and will not suddenly add a feature you never asked for. It also updates when it makes sense for you, not when a vendor decides.

  • A plugin doing exactly one job
  • Your own calculation and validation rules
  • Admin screens your staff understand

02

Rescuing and modernising legacy code

An application on PHP 5 or 7 is both a security and an operational risk, yet rewriting from scratch is often needlessly expensive. I work in steps instead. First I establish what the application really does and which parts are still used. Then I remove constructs that no longer work on the new version, add input validation and proper error states, and only afterwards address structure. Where possible I move dependencies to Composer and split the code so parts can be tested in isolation. The result is an application running on a supported PHP version that can still be worked on two years from now.

  • A staged move to PHP 8.3
  • Removal of broken legacy constructs
  • Composer and separated components

03

Server-side logic you can trust

The server side decides whether the output can be trusted, so the work concentrates on things nobody sees on screen: input validation, permissions, transactions around writes, correct rounding of money, time zone handling and the states that appear when two people change the same record at once. Important operations are written to an audit trail so a change can be traced back to a person and a moment. These are exactly the details behind the bugs that only appear at volume, and they are the hardest ones to find afterwards.

  • Validation, permissions and transactions
  • Correct money and date handling
  • Audit trail for key operations

04

Data migrations and the WordPress side

A large share of PHP work is migration: moving to a new version of a system, transferring data from an old database, reshaping a content structure or merging two systems into one. I write migration scripts that can be run repeatedly and that produce a report of what transferred and what failed. Because so many projects run on WordPress, PHP work often takes that shape: plugins, theme-level changes, custom REST endpoints and WP-CLI commands for scheduled tasks. The same principles apply to standalone applications with no WordPress involved at all.

  • Repeatable migration scripts
  • Reports of transferred and failed rows
  • Plugins, REST endpoints and WP-CLI

05

Handing over code someone else can take on

I write code expecting another developer to read it one day. That means understandable names, separated responsibilities, notes where a decision is not obvious, and a short description of how the project is run and deployed. On larger pieces I add tests where a mistake would cost the most, plus static analysis so a share of problems surfaces before deployment rather than after. The goal is not dependency on me. If your company hires its own developer next year, they should be able to pick the project up without starting again.

  • Readable structure and decision notes
  • Tests where failure costs most
  • Documented run and deploy steps

?

Common questions about PHP development

How much does custom PHP development cost?

A smaller plugin or behaviour change is usually 4 to 12 hours, a larger module 15 to 40 hours. At €40 per hour including VAT that puts the range at roughly €160 upwards. For an inherited project I refine the estimate once I have seen the code.

How is this different from the Laravel page?

Laravel is a specific framework and suits larger applications with their own data model and roles. This page is about PHP itself: custom plugins, server-side logic and work inside existing code that either uses no framework or uses a different one.

Will you take over a project from another developer?

Yes, that is routine. I review the code, versions, hosting and backups first, then say what is urgent and what can wait. Only after that do I propose a scope. I recommend a rewrite only when it is demonstrably cheaper than continued repair.

Can the move to PHP 8.3 happen without downtime?

In most cases yes. Changes are prepared and tested away from production, the switch is scheduled for a quieter period and a way back stays ready. Downtime is then a matter of minutes rather than hours.

Do you write tests and documentation?

Yes, in proportion to the work. For critical logic, calculations and integrations tests pay for themselves; for a simple plugin they would be needlessly expensive. A short description of running, deploying and configuring the project is always part of handover.

Have something in PHP to build or rescue?

Tell me what the project is and which PHP version it runs on. I will look at it and say what is urgent and what can wait.

Discuss a PHP project