fourth post in the training tracker series: turning the AI coach spec into a running endpoint, the bugs that only showed up once something real was talking to it, a security gap closed before a second user existed, and a chat UI to finally use the thing.
third post in the training tracker series: migrating the data model from single-user to multi-tenant before the second user exists, and writing the specs for an AI coach before writing a line of its code.
second post in the training tracker series: before adding a single new feature, the working single-user app gets a proper security review. What an audit of a small web app actually looks at, and why shipping something is the start of the job, not the end of it.
first post in the training tracker series: provisioning the AWS infrastructure, designing the data model, and seeding 105 days of plan data into DynamoDB.
I asked one of these models how many days of the week have a ’d’ in them. It got it wrong — in different ways across different sessions. So I asked Claude to write about its own unreliability.
A CISA contractor exposed credentials, config files, and access tokens in a public GitHub repository. I had a smaller incident with a similar pattern — and a very different blast radius — in April.
A billing audit of the tacedata.ca AWS account — what was accumulating, what was surprising, and how infrastructure that was supposed to cost nothing ended up at $59/month.
Setting up server-side traffic analytics for tacedata.ca — and hitting a hard wall in the CloudFront Free pricing plan that blocks all logging features.
sixth post in the series: adding threshold detection and SNS email alerts so meaningful indicator crossings surface without having to check the dashboard.
fifth post in the series: adding a DynamoDB snapshot store so the dashboard can display 3-month and 6-month sparklines alongside the existing 30-day view.