< What I Do />
Different problems, one rule behind all of them: a system should never fail the person relying on it in silence. Whether your team calls it a preflight check, a sanity check, validation, or guardrails, the job is the same: catch the bad state before it ships, and say so plainly when you do.
Configuration & Validation
One wrong value shouldn't be able to take down production. I make sure it can't.
See the product →AI Workflow Reliability
AI features that loop, drift, or break silently — made deterministic and traceable.
See the product →Developer Tooling
The fragile manual step everyone dreads, turned into one safe command.
Scientific Software
Research pipelines that give the same answer twice — and that others can reproduce.
Systems Architecture
The failure modes hiding in your system, made visible before they bite.
Trusted by users, contributors, and engineering teams
- Shipped Pyxel Config Lab in the official ESA Pyxel 2.14 release
- Ships pyxel-config-core and the LLM Workflow Router on PyPI
- Built Nimbus Vestige — self-hosted forensic reconstruction for cloud identity incidents
- Built Nexa — an offline, self-checking validation assistant for Odoo
- Merged contributor to GitLab core systems
- Featured in This Week in 4n6 for research on cloud identity forensic reconstruction
For small businesses & independent founders
< Founding Client Program />
Testing and validation shouldn’t be a luxury only big teams can afford. Most of my work is with businesses that have no engineering department at all — the software that runs the place was set up by someone who has since moved on, and it mostly behaves. So I’ve built an accessible first step: a focused, read-only look at the part most likely to fail quietly — for one clear price, agreed before anything starts.
Sound familiar?
- Something breaks after a setting is changed, and nobody can say which change did it.
- Two systems that should agree — stock, prices, bookings, invoices — keep drifting apart.
- A job that runs overnight sometimes doesn’t, and you hear about it from a customer first.
- The person who set it all up has moved on, and nobody wants to touch it.
- An AI feature you’ve added mostly works, except when it quietly doesn’t.
- You’re paying to fix the same thing more than once.
If two or three of those landed, that’s what the review below is for. If none of them did, you probably don’t need me yet — and I’d rather say so than sell you a review.
Starter Reliability Review
£200 fixed
- One small service or pipeline — a slice, not a whole estate
- A read-only pass over its config and structure
- Prioritised findings in plain language, plus one follow-up
Fixes, bigger reviews and ongoing cover are all fixed-price too, and returning clients keep a standing 25% thank-you. Full breakdown on the services page.
Cited in the peer-reviewed literature
< Named in an ESA & ESO Paper />
“Notably, Doby Baxter has led the development of a new GUI, making Pyxel more accessible to users from a broader range of scientific and engineering backgrounds.”
Lemmel, F., Affatato, V., Jha, A., Hernandez, E., Prod’homme, T., Serra, B., George, E., and Mansour, M., “Pyxel 3.0: New features and applications for the collaborative instrument simulator,” Proc. SPIE 14157, X-Ray, Optical, and Infrared Detectors for Astronomy XII, 141571I (19 August 2026).
Read the paper — doi:10.1117/12.3104656 →Professional endorsement
"Doby has demonstrated strong technical skills, thoughtful system-level thinking, and a clear focus on usability and maintainability. He played a key role in developing innovative tooling driven by real user and community needs. He is proactive, reliable, and communicates clearly, particularly when working on complex or cross-cutting features."
The standard behind the work
< No Silent Failure />
I met these systems as a person long before I worked on them as an engineer: they rarely crashed, they failed quietly, and left the person to find out through the consequence. A system missing any one of these six musts is not fit for purpose, whatever its dashboards say.
The six musts, in short
- Publish the limits, the criteria, and the legal duties, and make them enforceable. An unenforced limit is decoration.
- Failing is allowed. Failing quietly is not.
- Measure what changed for the person, not how much the system moved.
- Count the people it turned away, and know what became of them.
- The system carries the context, not the person.
- Never require the thing you exist to provide.
And underneath all six: none of it counts without a layer that enforces it. A right nobody can enforce and a rule nobody validates fail the same way. Free to take and apply to something you own, whether or not you ever hire me.
Independent vision · open blueprint
< Social Resource Floor />
A separate, long-term idea of mine, held at arm’s length from client work and open to collaborators.
A floor beneath which no person should fall
Human survival should not depend on financial access.
An open blueprint for a coordination layer above existing social-protection systems like OpenSPP and OpenG2P, not a replacement for them. Survival today has a single point of failure: lose access through one gatekeeper and everything downstream goes with it. The floor adds redundancy, so the failure of one route never becomes the failure of the person.
Contributors from social protection, engineering, policy, or lived experience are welcome.
< Let's build something reliable />
Whatever's breaking — or about to — tell me what you're working on.
Doby Baxter
No account managers and no hand-offs — you work with me directly. I read every message myself: starter enquiries get an answer within one working day, and everything else within a few days.