Mostly Java backend work, and the parts around it: the deployment, the database, and the review that tells you whether a plan is sound before it is built.
Building and extending Spring Boot services that depend on each other.
Finding out why it is slow, then fixing the cause.
Getting it running somewhere you control.
A second opinion, in writing.
Worth being concrete about, because it is the part most often handed back as a zip file. This site is the example: an Astro build served as static files by nginx, and a Spring Boot API behind it, on a Hetzner CX33 running Fedora.
Every container runs rootless under an unprivileged user, from one compose file per project and no long-lived daemon. Each service has a memory and CPU cap, a read-only filesystem and a health check, so a leak in one stack cannot become an outage in the other. TLS is Let’s Encrypt, obtained and renewed automatically by the edge proxy, with no timer or cron job to maintain.
Releasing is a git tag: CI runs the tests, builds the image and pushes it to the registry. Deploying is a pull and a restart on the host, and rolling back is changing one version number. The whole provisioning sequence for a fresh host - firewall, rootless Podman, certificate issuance - is written down as a runbook and lives in the same repository as the code, because a deployment nobody else can reproduce is not finished.
This box runs a second, unrelated project as well, and the two are genuinely independent: neither repository references the other, and either can be deployed or torn down without touching the other. Ports 80 and 443 belong to a shared proxy owned by neither project, each stack keeps its own private network, and nothing stateful is reachable across the boundary. Sharing hardware is a cost decision; sharing a blast radius is a separate one, and these two stacks share only the hardware.
None of this is a claim you have to take on trust. This site’s source - the nginx config, the compose file, the release pipeline and the provisioning runbook included - is public on Codeberg.
A specific outcome with a fixed scope: an upgrade, a service, a performance problem. Priced per project once we both understand it.
A regular slice of time over a few months, as part of your team. Priced per day. This is the usual shape.
A codebase or architecture read in a few days, ending in a written report you can hand to a stakeholder. Fixed price.
I take on one or two engagements at a time, so the work gets the attention it needs. I do not take on work that competes with my employer, or that draws on anything confidential to them.
Rates depend on scope and duration: ask and I will give you a number rather than a range. I am happy to work through your agency’s contract if that is simpler.