We sell business systems and automation. The most direct evidence that we mean it is how we run ourselves — and this is the one case in this section with no client in it at all. Everything below is our own infrastructure, running against our own work.
Recurring maintenance across a portfolio of sites used to be hand-operated: open a session, work through sites one at a time, remember which ones failed, write down what was completed afterwards.
That last step is where it broke. The completion record was written by the same person who did the work, from memory — which means a missed pass and a completed pass look identical in the record. A cycle went stale for four weeks without anyone noticing, because nothing in the system was positioned to notice.
It now runs unattended, and the design constraints are the interesting part. It widens no permission: every action goes through the same access path a person would use, and a write only executes if it is on an explicit allow-list — anything else is reported as gated rather than performed. It holds what it should not decide: major version upgrades are reported, never applied unattended, and an unparseable version is classified as major, which is the conservative direction. And it never invents a completion — a step with no recipe, an unreachable target, or a failed command is recorded as exactly that, and the completion timestamp is not written. A false completion record is worse than a missing one, because it is precisely the state the freshness check exists to detect and cannot.
Its own test suite caught a real defect before it shipped: it was reporting a gated decision as a tooling gap. Opposite meanings, identical symptom — one says build something, the other says someone has to decide. Only a test distinguished them.
Deterministic work does not go to a model
We use AI heavily, and we are specific about where. Anything a client will check against their own records — dates, counts, money — is computed by ordinary code with a test suite, not generated. Models are used for judgement, classification, drafting, and research. The lead-response analysis we offer prospects is built this way: a deterministic engine with its own tests, and a browser version generated from the same core so the two cannot disagree, with a continuous-integration check that fails the build if they drift apart.
Verification is wired in, not remembered
Every internal tool ships with a self-test that runs in continuous integration. Publication checks run against rendered output rather than source, because the defect that once reached production was a formatting bug invisible in the source file. A drift linter finds dead internal references and stale document dates. A state validator fails the build if our operational record stops parsing. Every one of those exists because something went wrong once — which is the honest account of where a good system comes from: not foresight, but refusing to fix the same class of problem twice.
Why it matters to you
We ask whether software or intelligence can scale a bottleneck before asking who to hire, and we apply that to ourselves first. A firm that automates your support triage while its own triage is manual is losing an argument inside its own building. It is also why the work is affordable: the leverage we build for ourselves is the reason a small firm can take on systems work that would normally need a team.
Client, vendor, product and industry details are removed, along with any figures belonging to the client. The technical detail is unchanged. This shows how we work — it is not a claim about a business result, which would require the client’s consent and a baseline measured before the work began.