Languages and frameworks
- PHP
- Symfony
- Laravel
- Go
Both sides of the migration question, which is what makes an honest answer to it possible.
About
An Independent Senior Backend Engineer, Working Directly With Your Team
One engineer, not an agency. I work on backend systems in PHP and Go for European product and SaaS companies: architecture decisions, legacy modernization, and the implementation that follows from them.
Senior enough to make the architecture decision. Small enough to work directly. Structured enough for European B2B procurement.
What I Work With
Deliberately a short list. It covers the areas where I can take responsibility for an outcome, rather than everything I have touched at some point.
Data and infrastructure
- PostgreSQL
- Redis
- Docker
- Kubernetes
Schema and query work, caching and queueing, and the container and deployment layer around a service.
Interfaces and operations
- HTTP and gRPC APIs
- Queues and workers
- Observability
- Incident debugging
The parts that decide whether a backend is pleasant or painful to run once it is live.
Private AI systems
- Local LLMs
- Speech-to-text
- Document search
- On-premise inference
Workflows that should run on infrastructure you control, when a public AI API is the wrong default.
How I Work
Measure before deciding
Profiling data and baseline metrics come before any architectural recommendation. Opinions about what is slow are wrong often enough to be worth checking.
Small reversible steps
Work is sequenced so each step can go to production on its own and be rolled back on its own. Long-lived branches and big-bang cutovers are where migrations go wrong.
Inside your process
Your repository, your review rules, your tracker, your deployment pipeline. Introducing a parallel process for one external engineer creates more problems than it solves.
Decisions written down
Architectural choices get a short written rationale, including the options rejected. That is what makes the work maintainable by your team after the engagement ends.
Honest capacity
One engineer means finite availability. When I do not have the time or the right experience for something, saying so is faster than everyone finding out in month two.
Direct communication
Technical discussion happens with the person doing the work, in your channels, without an account manager in between.
Why I Am Independent of the Rewrite Decision
Most people you can ask about a PHP to Go migration have a reason to want a particular answer. An agency with Go engineers on the bench needs Go projects. A platform vendor needs you on their platform. A team that has just learned a new language would quite like to use it. The recommendation follows the incentive, and it is usually delivered with confidence.
My engagements are priced the same whether the conclusion is "upgrade your PHP runtime and fix these six queries" or "extract this worker into Go". There is no bench to keep billable, no licence to resell, and no second team whose utilisation depends on the answer being a migration. The migration readiness audit is a fixed price precisely so the recommendation is not attached to the size of the project that follows.
That also means I will sometimes tell you the honest answer is disappointing: that the architecture is fine and the problem is a missing index, or that the real constraint is team process rather than technology. Those conversations are cheaper than a migration that did not need to happen.
Working Hours, Communication and Business Setup
I work in Europe/Belgrade, which is CET/CEST, a full working-day overlap with teams in Germany and the wider DACH region, the Netherlands, France, the Nordics and most of the EU. Reviews, planning and incident calls happen inside your working day rather than at the edges of it.
Communication is English, mostly asynchronous, in whichever channels your team already uses. Core hours, meeting cadence and any out-of-hours or incident expectations are agreed at the start of an engagement rather than left to be discovered later.
Contracting is business-to-business: one service agreement, monthly invoicing in EUR, and no employer of record or umbrella company in between. An NDA can be signed up front, and the rest of the commercial detail is set out on the contractor engagement page.
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
A short written description
The stack, roughly what the traffic and data volumes look like, and the problem as you currently understand it. A few paragraphs is enough.
A technical call
Thirty to sixty minutes with the engineer who would do the work. The goal is to establish whether the problem is what it appears to be and whether I am the right person for it.
A defined first step
Either a fixed-price migration readiness audit at €1,200, a private AI readiness audit from the same commercial model, or a 10-day paid pilot at €400 per day for a capacity question.
Contract and access
An NDA if you want one, then the service agreement covering scope, cadence and notice period. After that: access, a repository walkthrough and a real first ticket.
How to Evaluate Me
There is no case-study carousel on this site, and there are no logos or testimonials, because I am not going to publish client names and numbers I cannot substantiate. What I would offer instead is more useful during an evaluation anyway: a technical conversation about your own system, where you can judge whether the questions I ask are the right ones.
If you want to see how I reason before that call, the blog is there for exactly that purpose: architecture trade-offs, migration mechanics and the failure modes worth knowing about, with the reasoning shown rather than summarised. For a paid but low-commitment version, the entry points are deliberately small: a fixed-price migration readiness audit, aprivate AI readiness audit, or a10-day paid pilot.
Getting started
Start with the problem, not the paperwork
A few paragraphs about the system and what is going wrong with it is enough to get a useful answer back. If it turns out I am not the right person for it, I will say so.