About
I build, modernize and operate backend systems in PHP and Go. Since 2018 I have worked on SaaS, high-load applications, distributed backend services and trading-related systems — from architecture and database performance to Kubernetes deployments and production incidents.
Senior Backend Developer · 2023–present
Backend Developer · 2019–2023
Backend Developer · 2018–2019
Two PHP products — Blog and Academy — each contained their own file and image upload implementation. The logic was duplicated, so upload and validation rules had to be kept in sync across more than one codebase.
I proposed extracting upload functionality into a separate backend service.
Implementation: a Go upload service, with both PHP backends integrated and one application migrated at a time.
Engineering benefit: one implementation of upload behaviour and validation, independently deployable and scalable upload capacity, and no need to scale a whole PHP application during image-heavy periods.
The extraction added another deployable service and a network dependency, so the boundary had to justify the additional operational complexity.
On production API and analytics paths, the first move was measurement rather than a runtime change.
Average response time of key API endpoints was reduced by 35%.
A separate analytics data path was reduced from approximately 12 seconds to 2 seconds using PostgreSQL and Elasticsearch.
The recurring pattern is to measure the bottleneck first — API code, SQL, data access, caching or architecture — before changing the runtime.
A high-load PHP service was re-architected in place rather than rewritten.
Peak throughput improved by 40%. PostgreSQL optimization reduced server CPU usage by 25%.
The result is a reminder that PHP → Go work is a selective extraction service, not an automatic migration into Go.
More than 50 projects shared a production alerts channel. Signal was drowned in repeated, non-actionable events, and important failures risked being lost in noise.
I initiated the review: classified actionable versus expected failures, fixed real bugs found during that pass, and removed or downgraded events that were not useful as production alerts — for example expected 422 invalid-input errors should not have the same severity as actual production failures.
The production channel became substantially less noisy and useful as an operational signal again.
The areas where I can take responsibility for an outcome, rather than everything I have touched at some point.
Production work on both sides of a PHP to Go decision, including cases where the runtime should not change.
Schema and query work, caching and search, and the container and deployment layer around a service.
The parts that decide whether a backend is pleasant or painful to run once it is live.
Workflows that should run on infrastructure you control, when a public AI API is the wrong default.
Profiling data and baseline metrics come before any architectural recommendation. Opinions about what is slow are wrong often enough to be worth checking.
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.
Your repository, your review rules, your tracker, your deployment pipeline. Introducing a parallel process for one external engineer creates more problems than it solves.
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.
The Migration Readiness Audit has a fixed price, so the recommendation does not depend on how much implementation work follows. The result can be upgrade, refactor, extract — or leave the component alone.
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 with a registered Serbian sole trader, monthly invoicing in EUR, and no employer of record. An NDA can be signed up front, and the rest of the commercial detail is set out on the contractor engagement page.
Working stack
Remote from Serbia, working hours overlapping CET/CEST. Engagements run on one B2B agreement with a monthly invoice in EUR.
The stack, roughly what the traffic and data volumes look like, and the problem as you currently understand it. A few paragraphs is enough.
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.
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 €300 per day for a capacity question.
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.
Getting started
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.