Observability: knowing your application is broken before residents tell you
Logs, metrics, and traces are not a luxury for public-facing systems. They are how you keep a promise.
Blog
Engineering posts
HQT blog posts on engineering for public agency technology teams.
Designing agency software for the counter and the phone at the same time
Staff at a counter and residents on a phone need different things from the same system. Both can be served well.
How we treat AI-generated code in delivery pipelines
Coding assistants are part of how software is written now. Here is what that changes about review and testing, and what it does not.
API-first integration for agencies that own a dozen vendor systems
How to connect commercial platforms without building a fragile web of point-to-point links.
Boring technology is the right default for systems that must run for a decade
Agency systems outlive the teams that choose them, so we default to components that will still be supportable, staffable, and patchable in ten years.
Stop testing with production data
Copying production databases into test environments is common, risky, and usually unnecessary. Here is the alternative.
What we mean when we say DevSecOps
The term is overused. Here is the concrete set of practices behind it on our projects.
Why we write the runbook before we write the feature
We draft the runbook for a new service before building the feature it describes, because the operational story surfaces design problems early.
Low-code or custom code? A decision guide for agencies
When a Power Platform or ServiceNow app is the right call, when it is not, and how to tell in advance.
Replacing a legacy application without a big-bang cutover
How the strangler pattern lets an agency modernize one function at a time while the old system keeps running.
A project is not finished until the agency can run it without the vendor
The artifacts and demonstrations an agency should require at closeout: code, pipelines, runbooks, credentials, and documentation.
What a good statement of work looks like for a software project
The sections we insist on before we start a software engagement, and why each one protects the agency as much as us.
Three integration failures that nobody notices until the data is wrong
File transfers, direct database access, and APIs each fail in a way that tells nobody. Here is how to make each failure visible.
Acceptance criteria that a tester can execute and a contract can rely on
Why "the system shall work" cannot be enforced, and how to write acceptance criteria that produce a clear pass or fail.
What a screen reader finds that an accessibility scanner does not
A practical walkthrough of testing an agency site with a screen reader: what to check, what breaks most often, and how to order the fixes.