54 of 85 production pull requests in four months were platform hardening rather than feature delivery.
| Theme | PRs | Work |
|---|---|---|
| Security | 26 | Clearing critical CVEs from a production image, stripping hardcoded credentials into managed secrets, mandatory TOTP two-factor with recovery codes, secret scanning, an automated key-rotation service. |
| Feature | 20 | Turning a feedback popup into a real ticketing pipeline, attachments, contact flows, CMS pages. |
| Infrastructure and deploy | 14 | Single-container serverless deploys, identity-proxy-gated staging, VPC connectors, private database networking, keyless CI-to-cloud authentication. |
| CI and governance | 14 | Pull-request check gates, dependency automation, two linters brought to zero findings, pre-commit and pre-push hooks. |
| Fixes | 12 | Crash and correctness work. |
| Backup and disaster recovery | 5 | Production data store backup, verification, and failure alerting to a dedicated channel. |
The rows sum to 91 against 85 distinct pull requests, because the themes are not mutually exclusive, a deploy change that also moves a hardcoded credential is counted as both infrastructure and security.
This work is described by category only. No employer, product, client, teammate or repository is named anywhere on this site.
Four months on a production platform, and the thing I did not expect is how little of it was features.
Fifty four of eighty five pull requests were hardening. Clearing critical vulnerabilities out of a production image. Taking credentials that were sitting in the codebase and moving them into managed secrets, then adding scanning so they could not quietly come back. Mandatory two factor sign in with recovery codes, so that turning it on could not lock anybody out. A service that rotates keys on its own schedule instead of waiting for somebody to remember. Staging put behind an identity proxy. Private networking between the application and its database. Continuous integration that authenticates to the cloud without a long lived key existing anywhere. Backups that verify themselves and raise an alarm when the verification fails.
None of that shows up in the product. All of it is the difference between shipping and shipping safely, and I found I would rather be the person who does it than the person who ships the feature on top of it.
It also explained the pattern I kept building by accident. Every one of those changes is the same idea as the policy module and the confidence floor: decide in advance what is allowed, put the decision somewhere it can be tested, and then let the fast moving part run inside it.
This work is described by category only. No employer, product, client, teammate or repository is named anywhere on this site, and that is deliberate rather than vague.