Tooling only helps when someone still uses it under pressure. These are the instruments and habits we hand over with every system, along with the runbooks that make them someone else's to operate afterwards.
Every engagement includes version control with review, automated testing appropriate to the risk, vulnerability scanning, structured logging and a written runbook describing how to restart, restore and roll back. These are deliverables rather than internal housekeeping, because a client should not need to keep us merely to know how their own system behaves under failure.
Infrastructure, scripts and documentation live alongside application code. Commit messages are written for whoever reads them in three years trying to understand why a constraint existed.
Default for hosting and review, with protected branches and required checks so production receives only reviewed, tested work. Its ubiquity also makes later handover to another firm straightforward.
Work is recorded where the client can see it, describing the problem rather than prescribing the solution. Backlogs written that way survive changes of personnel far better than technical task lists.
The Python standard here: fixtures, parameterised cases and integration suites backed by real databases. The discipline is speed, because a slow suite stops being run and an unrun suite protects nobody.
Unit testing for typed front-end and service logic, especially pricing, allocation and validation. Coverage is a by-product rather than a target, and the percentage is not something we present as success.
Browser-level tests protect the handful of journeys that must never break. The suite stays small deliberately, since end-to-end tests scale badly and a large one becomes a maintenance item of its own.
Integration tests run against genuine database, queue and cache instances started for the suite instead of mocks. Slower per test, yet it exposes transaction and constraint problems mocks reliably conceal.
Static analysis flags duplication, complexity and unreachable code on every request. Findings are advisory except where security is concerned, since blocking on style teaches people to bypass the process.
Automated checks against published vulnerability lists, with severity mapped to response windows agreed in writing. Updates arrive monthly in one batch, which keeps review meaningful rather than reflexive.
Every push is scanned for credentials before reaching a shared branch, with history rewritten where something leaked. Preventing a commit costs far less than rotating an exposed key afterwards.
Instrumentation is written to a vendor-neutral standard so traces and metrics survive a change of monitoring backend. That portability is the argument, since re-instrumenting later is thankless work.
Used where a client hosts its own dashboards, particularly estate metrics spanning several systems. They require an owner who understands retention and cardinality, or storage and cost quietly expand.
Error aggregation with release tracking, attributing a defect to the deployment that caused it. Sampling and payload scrubbing are configured carefully so client records never arrive unfiltered.
Testing and monitoring decisions are allocation decisions: budget one team has and another does not.
Unit tests cover calculations and rules because they are fast and precise. Integration tests protect data access and transaction boundaries. Browser tests cover only journeys whose failure is unacceptable, since each additional one adds runtime and fragility.
A percentage target encourages tests written for the metric rather than the risk. We instead name the paths that carry money, compliance or safety, test those properly, and accept known gaps openly rather than hiding them behind an average.
Short-lived branches suit teams releasing continuously and reviewing promptly. Long-lived release branches suit clients with formal change windows and separate support regimes, provided merges back happen before divergence becomes painful.
Only conditions requiring action within minutes should interrupt someone overnight: unavailability, failed payments, missed batches. Everything else becomes a ticket with a defined review time, because alerting without consequence trains people to ignore alerts.
Habits formed after watching well-intentioned setups decay within a year.
An intermittent test loses credibility quickly. It is disabled with a written reason, an owner and a date for repair, because silently deleting it removes the only evidence that the behaviour was once worth checking.
Suites seeded with tidy invented records never reveal performance or constraint problems. We anonymise extracts from production shapes so volumes, null patterns and awkward values appear before release rather than after.
An alarm with no documented first response becomes noise within a month. Each rule names who acts, what to check first and when to escalate, which is also what makes a support handover to another provider possible.
Staging and review stacks are scheduled down outside working hours in AWST. A few permanently running non-production databases can quietly rival production spend for a workload nobody measures.
Panels accumulated without purpose turn into decoration nobody opens during an incident. Each dashboard corresponds to a decision someone makes, and anything not consulted in months is deleted rather than maintained.
Promises we do not make, stated here rather than discovered later.
We do not gate releases on a quality server or dashboard that no one owns and patches. Unmaintained tooling decays into decoration within a year, and a failing check everyone ignores is worse than no check at all.
Generated or assisted output enters a repository only after reading, testing and understanding it. Plausible code that nobody has reasoned about is how subtle defects reach production, whatever produced the text.
No service receives client data until its storage locations are confirmed in writing. This rules out some otherwise excellent products, and that is an acceptable consequence of operating under Australian privacy obligations.
We do not tell clients a system is comprehensively tested. We state which behaviours are covered automatically, which rely on monitoring after the fact, and which remain manual, then agree which gaps are acceptable.
We review testing, monitoring and handover documentation before quoting any remediation.
