Services
What I build
Four services, one method: model the data, make the rules explicit, and put the whole thing under version control so it can be rebuilt from source years later.
Engagements
-
Document automation
A document family — quotes, statements, certificates, reports — turned into a pipeline with a declared input contract. Wrong data stops the build; it does not reach a customer.
- Schema and payload kept separate
- One template, validated inputs, no silent defaults
- Built by the same command in CI and on a laptop
Typically a fixed-scope first phase, then hourly.
-
LuaLaTeX engineering
Deep work on the typesetting engine itself: float placement, custom classes, package internals, Lua extensions, and the failures that only appear at volume.
- Engine-level debugging, not workarounds
- Package and class development
- Upstream fixes contributed where they belong
Hourly. Specialist rate.
-
Standards-conformant PDF
Archiving and accessibility done as engineering rather than as a badge: PDF/A-4f for reproducibility, PDF/UA-2 tagging where a real structure tree exists to back the claim.
- Embedded sources, so the file carries its own provenance
- Tagging asserted only where it is genuinely there
- Validation wired into the build
Often an add-on to an automation project.
-
Back-office systems
The application around the documents: registration, workflow, reporting, integration. Deployed as infrastructure as code, on servers you control.
- Free software throughout
- Reproducible deployment, no hand-configured servers
- Handover includes the infrastructure, not just the app
Project or retainer.
How an engagement runs
The awkward document
You send the thing that keeps going wrong. I read it and tell you what is actually broken, which is often not what it looks like.
Scoped first phase
A fixed, small piece of work with a result you can judge: one document family automated end to end, or one engine problem fixed.
Build and hand over
The pipeline, the sources, the deployment and the documentation. You can run it without me — that is the test I build against.
Keep it alive
Optional maintenance for the parts that move: engine upgrades, standards changes, new document types in the same family.
What I will tell you not to do
Structure has a cost, and adding it before it has earned its place is the most common way document projects become expensive. A validated data interface is the right answer for a document family that gets issued every month. It is the wrong answer for a document that has been issued once, whose sections still change between drafts.
So I will say so. If the honest answer is "write it by hand this year and automate it when you have issued it six times", that is the answer you get, and it is cheaper for you than the alternative.
Tell me what has to be right
A short description of the document and what goes wrong with it is enough to start. You will get an assessment, not a brochure.