For weeks the work has pointed outward — a client's site carried from paperwork to a tested build, a contact pipeline stood up and proven on the bench. This week the practice turned that same care on something of its own: a small tool for the workbench, taken from an empty repository to a working set of services across a single concentrated week.
The week belonged to a new internal developer tool — a cron-expression calculator, describer and comparer — which accounted for thirty-two of the items closed. It began where an honest project ought to: with the ground rather than the building. A repository initialised with its licence, editor configuration and contribution notes; a solution laid out across three source projects and five test projects; centralised build properties, a pinned SDK and a full analyzer set wired in so the compiler holds the line; central package management configured; a continuous-integration pipeline authored; automated dependency updates switched on; branch protection enabled so nothing reaches the main branch unbuilt; a domain registered for it; a thorough README and the first architecture-decision records written; and working code-coverage measurement stood up over the test suite. Foundations before features — the discipline we bring to client work, turned on our own.
On that footing the domain layer went in — the vocabulary the tool reasons in before it does anything useful. A cron-expression type with three concrete flavours beneath it; dedicated result and error types, so a malformed expression is a value to be handled rather than an exception to be thrown; the field and token types, and the value objects for fire-times and occurrences; a record to carry the difference between two expressions; and structural equality, so that two expressions meaning the same thing are treated as the same thing. Small, exact pieces, each tested as it landed.
Then the parsers — the part that meets the untidy real world. Three dialects of cron are in common use and they do not agree with one another, so the tool reads all three: classic Unix cron, the Quartz scheduler format, and a major cloud provider's event-scheduler syntax. Where a mature, well-worn library already does the reading well, the tool leans on it rather than reinventing it; where none fit cleanly — the cloud dialect — a bespoke parser was written and held to full test coverage, on the principle that a parser which is quietly wrong is worse than one that is plainly absent. Beside it went an error-anchored tokeniser, so that when an expression is malformed the tool can point at the exact field at fault rather than merely shrug.
— On tools —A practice is known by the tools it keeps. This week we made one of our own — and held it to the standard we hold the work.
With parsing solid, the services that make it useful went on top: a calculator that works out the next fire-times for each flavour; a describer that renders an expression into plain, flavour-aware English; an exporter that writes a schedule out as a standard calendar file, entirely in the browser; a comparer that diffs two expressions by what they actually do rather than how they are written; and a set of validation rules over the input form. Read a thing, explain it, schedule it, compare it — each layer resting on a finished one beneath.
Running alongside, the enterprise e-commerce platform's steady-state support kept its now-ordinary cadence. Last week's forward thread — a third-party connector into the ERP platform — advanced from scoping into building: the integration researched, a configuration service written, and the service itself stood up. And two production issues were traced and closed, both around inventory transfers out of the ERP — one where certain stock-keeping units were dropping from transfers, another where instant transfers were not arriving at all. Found, followed across the systems involved, and resolved.
The smaller stewardship was quietly kept. For the retained veterinary practice, a round of website updates — a senior-clinic section and revised pricing — and a clear-down of accumulated contact-form entries, the unglamorous hygiene that keeps a small site in good health. And the clinical canine massage practice, last week's headline, narrowed to a single thread held deliberately in flight: moving its contact pipeline from a stub to the real thing — the production credential for a third-party transactional-email provider placed in the cloud host, and the live mail path proven end-to-end from the preview environment before it is trusted with real enquiries.
Looking ahead: the internal tool turns from its working core toward the surface a person actually touches — the interface, and the pre-release checks that decide when a thing is fit to be seen; the enterprise connector carries on from built toward proven; the canine massage practice's mail path closes out, and its site moves on toward launch; and the retained clients go on being kept, as they always are.
Thirty-nine items to Done across three projects — thirty-two of them a tool built for the practice itself, carried from an empty repository to working services in a single week. One thread held in flight. The deliberate, unhurried practice, this week turned inward: the same care we bring to a client's system, given to a tool of our own.