Senior backend engineer · PHP & Go · Europe

Senior backend engineering for PHP systems that outgrew their architecture

I work with European engineering teams on two things: deciding what to do with a legacy PHP system, and adding senior backend capacity to a team that is short one experienced engineer. Same person, same B2B agreement.

  • €400/day embedded backend capacity
  • €1200 fixed Migration Readiness Audit
  • CET/CEST working-hours overlap
  • EUR invoice monthly, one B2B agreement

migration-candidates.txt

monolith/
├── billing        keep in PHP · upgrade framework
├── admin          keep in PHP · low traffic
├── search         extract to Go · latency + CPU
├── event-pipeline extract to Go · throughput
└── reporting      keep, but move off the primary DB

decision first, code second

How we can work together

Engineering engagements, not staffing products. You talk to the person doing the work from the first call.

Position

Your PHP monolith does not necessarily need a rewrite

A rewrite is a decision with a multi-year cost, and it is the wrong default for most systems. I am paid to make the right architecture call, not the largest one.

01 · Measure

Find the actual constraint

Latency, throughput, database contention, deployment friction, or simply the cost of changing the code. Each of those has a different fix, and only some of them involve Go.

02 · Separate

Split the codebase by consequence

Most of a monolith is fine where it is. The interesting part is the handful of components whose load profile no longer matches the runtime they run on.

03 · Decide

Write the decision down

Keep, modernize, or extract, per component, with the reasoning, the risk and the sequencing. That document is what your team and your board can argue with.

What I work with

Backend only. No design, no frontend frameworks, no promises about parts of the system I do not touch.

Working stack

  • PHP
  • Symfony
  • Laravel
  • Go
  • PostgreSQL
  • MySQL
  • Redis
  • REST / gRPC APIs
  • RabbitMQ
  • Docker
  • Kubernetes
  • CI/CD

Remote from Serbia, working hours overlapping CET/CEST. Engagements run on one B2B agreement with a monthly invoice in EUR.

How an engagement starts

  1. 01

    Call

    30 minutes on the system, the constraint and the deadline. No sales layer in between.

  2. 02

    Scope

    A written scope: audit, implementation, or embedded capacity, with the price and what is out of scope.

  3. 03

    Agreement

    One B2B service agreement. NDA on request. Invoiced monthly in EUR, no intermediaries.

  4. 04

    Start

    Repository access, one real ticket, and a first pull request inside the first days of the engagement.

Blog

How I think about this work

All posts

Next step

Tell me what the system is doing

Stack, the constraint you are hitting, and the deadline you are working against. If a rewrite is the wrong answer, you will hear that on the first call.

Entity in Serbia · B2B agreement · invoiced in EUR · CET/CEST