Skip to content

What I do

From the first line of code to the server in production.

Four areas that hold each other up: the application, the data behind it, who is allowed to reach that data, and the machines it all runs on. I do all four, so you are never left holding code and having to find someone else to put it online.

  1. 001

    Backends and APIs

    The part that keeps the product alive: logins, orders, bookings, integrations and the day-to-day workflows. REST APIs for browser clients and gRPC between internal services, with contracts in protobuf, so a changed field breaks the build rather than production. I write plainly and on clear responsibilities first - KISS and SOLID - and then model the domain complexity on top of a solid foundation.

    StackGo, PHP, Symfony, Python. REST and gRPC, protobuf contracts, versioning, documentation generated from the code.

  2. 002

    Security and GDPR

    Role-based access through Keycloak, with authentication isolated in a separate layer the browser cannot go around. I hunt for vulnerabilities in dependencies and fix them before they matter, and passwords and keys live in a secrets manager rather than files left on a server. All development and testing runs against an anonymised copy of the database, and the anonymisation routine scrubs the backups too.

    StackKeycloak, RBAC, OIDC with PKCE, a secrets manager, anonymisation including backups, vulnerability auditing.

  3. 003

    Data and search

    Models that survive contact with reality and migrations that do not lose rows. I index against the queries that actually run, not the ones I expected at the start. Backups every minute for the last hour, hourly for the last day, daily for the last month, monthly for the last year and yearly after that - with restores available on demand and verified every night.

    StackPostgreSQL, MySQL, Redis, Elasticsearch, Neo4j. Modelling, migrations, indexing, backups and restore procedures.

  4. 004

    Cloud and monitoring

    I handle the whole deployment. Only load-balancer systems hold a public address; the application cluster and the database cluster have private addresses only and public traffic to them is blocked, with administration over VPN alone. Both clusters run across several nodes, so if one goes down the application stays up on the others. The nodes sit in data centres in different countries, for extra redundancy.

    StackDocker, Kubernetes, Hetzner, AWS, Cloudflare, Prometheus and Grafana.

And, when the project calls for it

Web interfaces

Almost every project has one: React 19 with TanStack Router and Query, TypeScript and Tailwind, with the types coming straight from the backend contracts, so a column renamed in the database does not become a blank page in production.

Mobile apps

Only where the thing is genuinely used on a phone. I start with an installable web app - no app store, no update to wait for - and move to native code when the hardware demands it: background GPS, the camera, or push notifications that have to arrive with the screen off. The driver app in Get Home Safe is a native Android build in Flutter for exactly that reason.

Musical programming

Where I started: real-time audio in C++ with JUCE, Max/MSP, Pure Data, SuperCollider and Eurorack hardware. When the latency budget is measured in samples, you pick up habits that stay with you.

What it looks like inside

Two architecture decisions, drawn.

These are the things I end up explaining in the first conversation anyway. Easier drawn than described.

Authentication

The browser never receives a token

Authentication goes through a separate identity server, and the exchange of the code for tokens happens on the server. All the browser ever gets is an httpOnly cookie that page JavaScript cannot read.

BrowserIntermediate layerIdentity serverAPI + database01 sign-in request02 redirect with a PKCE challenge03 the user enters their password04 redirect back, with a single-use code05 code plus the original secret, exchanged for tokens06 an httpOnly cookie, nothing else07 application calls, carrying the cookie08 token attached server-sideno direct route exists

The single-use code is worthless to anyone who intercepts it: the exchange also requires the secret generated at step one, which never leaves the server. Tokens are refreshed server-side without the user noticing, and the roles inside the token decide what each person may do.

Infrastructure

One public address, everything else closed

Traffic comes in through a load balancer and nowhere else. The application cluster and the database cluster hold private addresses only, and public traffic towards them is blocked outright.

PublicInternetedge filtering and protectionLoad balancerthe only public address · 80/443Private networkno public addressesApplication clustera separate space per projectnodecontrolnodecontrolnodecontrolnodeworkerDatabase clusterautomated replication and restoresnodedatanodedatanodedataprivate onlyAdministrationover VPN and nothing elseall direct public access is blocked

Each cluster runs across several nodes, so one node going down does not stop the application. Traffic between the applications and the databases never leaves for the internet, and administration has no public door at all: the only way in is the VPN.

Next step

Let us find out whether it fits.

One conversation is usually enough for us both to tell.

Request a quote