Why a Blog?
Now I Get It! is a project built by a human and an AI working together, and I wanted a place to be honest about that process -- what works, what breaks, what I've learned. A separate blog platform felt wrong. The content belongs with the product.
The goal was simple: Markdown in, styled HTML out, no CMS. I didn't want to manage a WordPress instance or bolt on a static site generator. The site already had a Lambda-based API, a DynamoDB backend, and CloudFront for delivery. A blog could ride the same rails.
The Blog System
The backend is a new Lambda handler with full CRUD -- create, read, update, and delete posts. Each endpoint is gated with a token stored in Secrets Manager, same pattern I was already using for admin operations. Blog posts live in DynamoDB as Markdown with metadata: title, slug, date, tags, and an optional hero image URL.
A rendering module converts the Markdown to HTML and wraps it in a template that matches the site's dark theme. Published pages go straight to S3 and get served through CloudFront. The listing page shows all posts as a vertical timeline with cards, tag filtering, and prev/next navigation between posts.
I shipped the initial POST and GET endpoints first, then added PUT and DELETE the same day once I realized I'd inevitably need to fix typos in published posts. Both editing and deleting trigger CloudFront cache invalidations so changes appear immediately -- no waiting for TTLs to expire.
One thing I like about this setup: there's no build step and no deploy step for content. I send Markdown to an API endpoint, and seconds later it's live on the site.
The Manual Problem
The blog worked great, but the process of actually writing a post was tedious. My development log captures everything as it happens -- decisions, bugs, lessons -- but turning a devlog entry into a blog post meant: picking an entry, rewriting it in a conversational tone, scrubbing it for security issues (account IDs, tokens, ARNs), formatting the YAML frontmatter, figuring out the next filename in the sequence, and then calling the API with the right credentials.
Every step was an opportunity to forget something. The security scrub is the one you really can't afford to skip.
Automating the Pipeline
I built a Claude Code skill called now-i-blog-it that handles the entire workflow. When invoked, it reads the devlog, cross-references existing posts to find entries that haven't been blogged yet, and presents a numbered list. I pick which entries to convert -- they can be combined into one post if thematically related -- and the skill rewrites them in the blog's voice.
Before publishing, it runs a security scrub against a checklist of patterns: AWS account IDs, API keys, secret ARNs, IP addresses, pre-signed URLs, profile names. The draft gets presented for approval, and only after sign-off does it hit the publish endpoint.
The skill ships with three reference files beyond the main instructions: a publish script that loads the blog token from the project's environment and POSTs to the API, a style guide distilled from reading every existing post, and the security scrub ruleset.
What I Like About This Approach
The skill doesn't touch HTML rendering at all. It sends Markdown to the same blog API, and the existing renderer handles presentation -- dark theme, navigation links, analytics. The skill stays focused on two things: content creation and security. Everything else is already solved.
There's a nice feedback loop here too. Each blog post I write through the skill tests the skill itself. If the voice drifts or the scrub misses something, I catch it during the approval step and can tighten the rules for next time.
The blog went from "I should write about this" to "let me invoke a command" -- which means it'll actually get used.