About

My work sits in the middle of software: Java services and the integration between them, data pipelines and the modelling that keeps them honest, React when an interface is the only way to answer the question. It is rarely the visible part of a product and usually the part that decides whether the product survives its second year.

The desktop tools come from the same instinct at a smaller scale. Local Route Launcher began as an annoyance — four steps where one would do — and ended as something that starts three applications behind one saved proxy, with two native builds, a release checklist and a set of limits I can state in a sentence. This site is the record of that: the tool, the notes written while building it, and the parts that did not go to plan.

Most of the problems I am useful for look the same from a distance: two systems that disagree about what a field means, a pipeline whose output is trusted more than it should be, an interface that exposes a data model nobody wanted to explain. The work is usually less about a framework than about making the disagreement visible early enough to fix it cheaply.

On the back end that means service boundaries, contracts and failure paths. On the data side it means collection, processing, quality checks and the modelling that lets someone still explain a number six months later. On the front end it means React built against an API I can also read, so the awkward cases show up in the interface rather than in a support ticket.

The five areas I would list as professional practice — with what I actually did in each — are on the work page, kept separate from the open-source projects because they are a different kind of evidence.

I try to start from a specific annoyance rather than a technology. Projects that begin with “I want to try this tool” tend to end as demos; projects that begin with “this takes four steps and should take one” tend to end as something still in use a year later.

I prefer the smallest change that answers the actual question, and I try to write the limitation down at the same moment as the feature. The two are much easier to remember together than apart — and a limitation written next to the button is the only kind anyone reads.

I use coding agents as part of the work: reading an unfamiliar codebase, drafting a change, running the checks, writing the first version of a test. They are good at producing something reviewable and bad at knowing when that something is subtly wrong — usually with confidence in proportion to how wrong it is.

So the interesting question is not what a model can generate. It is what the review step has to become: can the change be read by someone who did not write it, can the failure be reproduced, does the test fail when the fix is removed. That is the part I am trying to get better at, and it is why some notes here are about process rather than code.

I am open to work that has a clear constraint and a definition of done: a back-end or integration problem that has outgrown its spreadsheet, a data pipeline nobody trusts, an internal tool that should exist and does not, or a release process that needs to stop being exciting. I am also interested in AI-assisted development done with a review process rather than a demo.

I am less useful when a brief begins with a technology. If the requirement is “we want to use X”, the first useful question is what is costing you time now — and the honest answer sometimes has nothing to do with X. I would rather say that early than discover it in week three.

For paid work I need a written scope and a way to verify the result; everything else is negotiable. There is no agency behind this site — it is one engineer, and the capacity that implies.

GitHub is the most reliable place to reach me: github.com/oliver804. Issues and pull requests on the launcher are read. Email works too, but expect a slower reply than a well-described issue. English or Chinese, either is fine.

Hand-written HTML and one stylesheet, with a self-hosted typeface subset and no framework. The source is public, including the README that describes how to add a page: oliver804/oliver804.github.io.