Mihira
Work

What I work on.

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.

Packages

Two common shapes of work, described up front. Both are built on what I did for VestPlan, which you can use and whose source you can read. I give you a date once we have scoped the work together - not before.

For founders with an idea or a prototype

Launch: idea to production

A working web product on your own domain, with the boring parts done properly: tests, automatic deploys, backups, and a server you own.

  • A product real people can use, not a demo that only works on a laptop
  • Automated tests, so later changes do not quietly break what already works
  • Releases in one step, and a quick way back if one goes wrong
  • Backups of your data, restored at least once to prove they work
  • A server you control, at a small and predictable monthly cost

We start with the smallest version worth putting in front of users. You get short written updates, and the code sits in your repository from the first day.

In more detail

  • Java 21 and Spring Boot API, React front end, PostgreSQL with Flyway migrations
  • CI that runs the tests and builds container images on every release tag
  • Rootless Podman on a plain Linux host, behind Caddy with automatic TLS
  • Rollback by image version, and a provisioning runbook in the repository
For teams with a Spring Boot app already live

Production-readiness pack

Know when something breaks before your users tell you, and know why.

  • Dashboards for what matters: errors, slow requests, background jobs, the server itself
  • Alerts that reach a person before users notice a problem
  • The path of a slow request traced through your system, step by step
  • Test coverage visible on every change
  • Disk and memory kept within limits, so monitoring can never take the app down

Everything lands in your repository as configuration, with a written runbook, so your team owns it once I am gone.

In more detail

  • Micrometer metrics scraped by Prometheus, OpenTelemetry traces stored in Tempo
  • Grafana dashboards and datasources provisioned from files, not clicked together
  • Alert rules with unit tests (promtool) run in CI
  • Retention limits and trace sampling sized for the host
  • JaCoCo coverage reports and summaries on pull requests

Everything else I work on

Distributed systems and microservices

Building and extending Spring Boot services that depend on each other.

  • REST APIs with real validation, sensible error contracts and versioning
  • Service boundaries, messaging, retries and failure behaviour between services
  • Domain modelling and persistence mapping that does not fight the database
  • Bringing an inherited service back under test
  • Java version and Spring Boot upgrades, including the Jakarta namespace move

Database and performance

Finding out why it is slow, then fixing the cause.

  • Query plans, indexing, and the N+1 problems an ORM makes easy to write
  • Schema design and zero-downtime migrations
  • Profiling and load testing before and after, so the improvement is a number
  • Connection pool and transaction boundary review

Deployment and operations

Getting it running somewhere you control.

  • Rootless Podman with systemd Quadlet units on plain Linux hosts
  • nginx, TLS via Let’s Encrypt, and a deploy that is one command
  • Structured logging, health checks and backups that have been restored at least once
  • Moving off a managed platform without a rewrite

Review and advice

A second opinion, in writing.

  • Architecture and code review with concrete, prioritised findings
  • Technical due diligence on a codebase you are about to inherit
  • Pairing and mentoring for a team that is growing quickly
  • Interview and hiring support for backend roles

How I deploy

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 VestPlan as well, and the two stacks 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.

Working together

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.

Get in touch →